Policy constraint framework for sddc

Abstract

Some embodiments of the invention provide a method for processing a request to perform an operation on a resource in a software-defined data center (SDDC). In some embodiments, the resource is a software-defined (SD) resource. The method initially receives a request to perform an operation on a first resource in the SDDC. The method identifies a policy that matches (i.e., is applicable to) the received request for the first resource by comparing a set of attributes of the request to a set of attributes of a set of policies that impose constraints on operations specified for resources. In some embodiments, a number of sets of attributes of a number of policies can be expressed for resources at different hierarchical resource levels of the SDDC. When the identified policy specifies that the requested operation violates a constraint on operations specified for the first resource, the method rejects the received request.

Description

Technical Field

[0001] This application relates to a policy constraint framework for SDDC. Background Art

[0002] Today, software-defined data centers (SDDCs) are an important part of both private and public clouds. To manage an SDDC, a wide variety of organizational requirements must be imposed on the resources provided to its users. These include customizations / policies that are highly specific to each SDDC. These requirements go beyond role-based access control (RBAC). For example, these requirements can be firewall policies such as (1) the default firewall policy is whitelisting (no communication is allowed unless opened with an explicit firewall rule), (2) selected types of traffic are not allowed for a given workload / application, (3) only certain source network addresses can send traffic to a given workload, or (4) generic deny-all or allow-all rules are not allowed for a given router or workload. Supporting these policies adds further challenges when the infrastructure service is truly multi-tenant and each tenant has its own policies. Summary of the Invention

[0003] Some embodiments of the present invention provide a method for processing a request to perform an operation on a resource in a software-defined data center (SDDC). In some embodiments, the resource is a software-defined (SD) resource. The method initially receives a request to perform an operation on a first resource in the SDDC. The method identifies a policy that matches (i.e., is applicable to) the received request for the first resource by comparing a set of attributes of the request with a set of attributes of a set of policies that impose constraints on the operation specified for the resource. In some embodiments, multiple attribute sets for multiple policies can be expressed for resources at different hierarchical resource levels of the SDDC.

[0004] When the identified policy specifies that the requested operation violates the constraints of the operation specified for the first resource, the method rejects the received request. On the other hand, in some embodiments, when the identified policy specifies that the requested operation satisfies the constraints of the operation specified for the first resource, the method performs the operation associated with the received request. In other embodiments, the method performs the operation only if the request does not violate the constraints of any policy that matches the request. In some embodiments, the matching policy can be explicitly specified for the first resource or for the type of the resource, or can be indirectly specified for the first resource when the matching policy is defined for a second resource that is a parent resource of the first resource in the hierarchical resource level of the SDDC.

[0005] In some embodiments, the policies in the policy set are defined in a declarative format. Likewise, in some embodiments, examples of resources include forwarding elements (e.g., managed software switches and routers, logical switches and routers implemented by managed software switches and routers, etc.), physical or logical networks, physical or logical network segments, physical or logical network interfaces, computing elements (e.g., virtual machines, containers, etc.), and 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.).

[0006] In some embodiments, the method receives a plurality of policies prior to receiving a request and stores each of these policies in a storage device, whereby these policies are used to identify a policy that matches a subsequently received request. In some embodiments, the received policy includes a target that specifies one or more sets of data center resources to which the policy applies. It also includes an expression that specifies constraints on operations on the specified set of resources. In some embodiments, the received policy is expressed in a declarative format.

[0007] In some embodiments, the target of each policy includes a resource type for a specified set of resources and a path prefix that identifies the specified set of resources in a resource hierarchy of a data center. In some embodiments, the expression for the received policy specifies one or more constraints on the operations that can be specified on the target set of resources of the policy. An example of a constraint is a value constraint that limits the value of an attribute of a resource that is the target of the policy. In some embodiments, the value constraint includes an operator that is one of an include operator, an exclude operator, or an equality operator. Another example of a constraint is an entity instance count constraint that limits the number of instances of a target resource. Yet another example is a related attribute constraint that limits the value of a secondary attribute of a target resource that has a primary attribute defined by the value constraint.

[0008] When a first resource that is the target operation of a received request is at a particular level in a resource hierarchy, in some embodiments, the method identifies a policy associated with the first resource by comparing a set of attributes of the request with a set of attributes of a policy specified for the first resource or a parent resource of the first resource in the resource hierarchy. In some embodiments, examples of the requested operation on the target resource include creating or modifying a forwarding rule for forwarding data messages, creating or modifying a service rule for performing a middlebox service operation on a data message, and deploying or modifying the deployment of machines and / or network elements in a data center.

[0009] The preceding summary is intended to serve as a brief introduction to some embodiments of the present invention. It is not intended to be an introduction or overview of all inventive subject matter disclosed in this document. The following detailed description and the accompanying drawings referenced in the detailed description further illustrate the embodiments described in the summary, as well as other embodiments. Therefore, a comprehensive review of the summary, detailed description, drawings, and claims is required to understand all of the embodiments described in this document. Furthermore, the claimed subject matter is not limited by the illustrative details in the summary, detailed description, and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The novel features of the invention are set forth in the appended claims. However, for purposes of illustration, several embodiments of the invention are set forth in the following figures.

[0011] Figure 1 An example of a policy framework of some embodiments is illustrated.

[0012] Figure 2 An example of a received policy is illustrated.

[0013] Figure 3 An object diagram of the different components of a strategy in some embodiments is presented.

[0014] Figure 4 The diagram shows how, in some embodiments, Figure 2 An example of a strategy provided to a strategy input processor.

[0015] Figure 5 Another example of a strategy is shown.

[0016] Figure 6 Illustrated is the processing that a request handler and policy framework perform to handle APIs for software-defined resources in an SDDC.

[0017] Figure 7 A computer system for implementing some embodiments of the present invention is conceptually illustrated. DETAILED DESCRIPTION

[0018] In the following detailed description of the 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 the present invention can be practiced without some of the specific details and examples discussed.

[0019] Some embodiments of the present invention provide a policy framework for validating requests to perform operations on resources in a software-defined data center (SDDC). In some embodiments, the resources are software-defined (SD) resources. When the policy framework receives a request to perform an operation on a first resource in the SDDC, it identifies one or more policies that match (i.e., are applicable to) the received request for the first resource by comparing a set of attributes of the request with a set of attributes of policies that impose constraints on the operation specified for the resource. In some embodiments, multiple attribute sets for multiple policies can be expressed for resources at different hierarchical resource levels of the SDDC.

[0020] When the policy identified for a received request specifies that the requested operation violates a constraint on the operation specified for the first resource, the policy framework rejects the received request. On the other hand, when the request does not violate the constraints of any identified policy that matches the request, the framework validates the operation. In some embodiments, a matching policy can be explicitly specified for the first resource or for the type of resource, or can be indirectly specified for the first resource when a matching policy is defined for a second resource that is a parent resource of the first resource in the hierarchical resource level of the SDDC.

[0021] In some embodiments, the policies in the policy set are defined in a declarative format. Likewise, in some embodiments, examples of resources include forwarding elements (e.g., managed software switches and routers, logical switches and routers implemented by managed software switches and routers, etc.), physical or logical networks, physical or logical network segments, physical or logical network interfaces, computing elements (e.g., virtual machines, containers, etc.), and 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.).

[0022] When a first resource that is the target of a received request is at a particular level in a resource hierarchy, in some embodiments, the policy framework identifies a policy associated with the first resource by comparing a set of attributes of the request with a set of attributes of a policy specified for the first resource or a parent resource of the first resource in the resource hierarchy. In some embodiments, examples of the requested operation on the target resource include creating or modifying a forwarding rule for forwarding data messages, creating or modifying a service rule for performing a middlebox service operation on a data message, and deploying or modifying the deployment of machines and / or network elements in a data center.

[0023] Figure 1An example of a policy framework 100 of some embodiments is illustrated. As shown, the framework includes a policy store 105, a policy input engine 110, and a policy check engine 115. As further described below, the framework interacts with a policy input processor 120 to store policies in the policy store 105 and with a request processor 125 to validate requests to perform operations on several SDDC resources 140.

[0024] For any request validated by the framework, request handler 125 uses one or more resource managers 130 to perform the operations associated with the request. As further described below, resource managers 130 perform operations by interacting directly with SDDC resources or indirectly through local and / or remote controllers. In some embodiments, request handler 125, policy framework 100, input handler 120, and resource managers 130 execute on different machines (e.g., VMs, containers, standalone servers, etc.) in one or more data centers and communicate with each other over a network.

[0025] In some embodiments, the policy input processor 120 is an API processor that processes input policy API commands received through the API gateway of the SDDC management system to which the policy framework belongs, or through the user interface presented to the SDDC administrator, SDDC tenant, and / or SDDC network by the SDDC management system. Through these API commands, the policy input processor 120 receives several policies and stores each of these policies in a storage device that it uses to identify the policy that matches a subsequently received request.

[0026] In some embodiments, the received policy is expressed in a declarative format. Figure 2 An example of a received policy 200 is shown. As described below, this policy restricts access to destination machines in the destination group to http and https access. Figure 2 As shown, a policy includes (1) a target 205 that specifies one or more sets of data center resources to which the policy applies, and (2) an expression 210 that specifies constraints on operations on the set of target resources. Figure 3 It is further shown in Figure 3 An object diagram 300 of the different components of a strategy in some embodiments is presented. Figure 3 In the example shown, the policy is specified for a given tenant 305 .

[0027] In some embodiments, the target of each policy includes (1) a type 212 of the target resource collection, (2) a name 214 of the target resource collection, and (3) a path prefix 216 that identifies the target resource collection in the resource hierarchy of the data center. As shown, in some embodiments, the policy path 216 is in URL format to uniquely identify a resource or resource collection in the data center. In some embodiments, the type and path prefix attributes of the target 205 are used to determine whether the policy is applicable to (i.e., associated with) an API request (i.e., whether the policy matches a set of attributes associated with the API request).

[0028] The path prefix 216 of the policy is specified by referencing one or more resources in the resource hierarchy of the SDDC. Figure 2 In the examples shown in some other figures of this application, the resource hierarchy of a data center includes the following resources: tenants, domains, communication maps, and communication entries. A tenant is a tenant entity (e.g., a business entity) that is a tenant of a multi-tenant data center. A domain is a workload under a tenant. A communication map is a set of communication rules under a domain that applies to communications to and from VMs in that domain, while a communication entry is a single communication rule (e.g., a firewall rule) under a communication map.

[0029] In some embodiments, a workload is an application or system deployed by a user for a specific purpose. An example of a workload includes all VMs deployed to run the Outlook application in an enterprise. Another example includes VMs deployed using a three-tier application template that specifies a web server, an application server, a database server, and zero or more middlebox service machines (e.g., a load balancer, a firewall, etc.) between the different tiers of the application. Other examples of workloads include a Sharepoint workload, a Windows server VM, a Windows VDI service VM, etc.

[0030] In some embodiments, examples of communication mappings include (1) a distributed firewall (a firewall machine implemented on a host machine with compute node VMs and / or containers), (2) an edge firewall device or machine operating at the north / south boundary of a physical or logical network, and (3) a plug-in service module that executes on a host computer to provide other middlebox service operations for compute node VMs and / or containers executing on the host computer. In some embodiments, an example of a communication entry includes a tuple that includes the following information: identifier, name, description, source group, destination group, service, action, and scope.

[0031] In some embodiments, a path prefix may identify a resource or collection of resources by specifying a path through a resource hierarchy from the root to the identified resource or collection of resources, where all taxonomic parents are contained in the path. For example, a first policy may be specified for all resources associated with tenant VMware by specifying the path as / vmware. A second policy may be specified for the Outlook workload of tenant VMware by using the path / vmware / domains / Outlook. A third policy may be specified for the web-profile of the Outlook workload of tenant VMware by specifying the path / vmware / domains / Outlook / communication-maps / web-profile. A fourth policy may be specified for open browser access for the Outlook workload of tenant VMware by using / vmware / domains / Outlook / communicationmaps / web-profile / communication-entries / open-browser-access. More generally, the format of the path to a security policy may be specified as: / <tenant-name> / domains / <workload-name> / communication-maps / <security-policy-name> / communication-entries / <rule-name>.

[0032] In the above example, the first policy applies to any resource to which the second, third, and fourth policies apply, the second policy applies to any resource to which the third and fourth policies apply, and the third policy applies to any resource to which the fourth policy applies. This is because the path prefix of the first policy is a subset of the path prefixes of the second, third, and fourth policies, the path prefix of the second policy is a subset of the path prefixes of the third and fourth policies, and the path prefix of the third policy is a subset of the path prefix of the fourth policy. Under this approach, the policy that applies to a resource is the policy that is specified for the resource or a parent resource of the resource in the resource hierarchy. Once a policy has been identified as applicable to the resource for which an operation is requested, the expression of the policy must be analyzed to determine whether the policy specifies constraints that allow, restrict, or deny the operation, as described further below.

[0033] Table 1 provides several other examples of path prefixes for some embodiments. These embodiments have several additional types of resources, including: provider to identify a router operated by an SDDC provider, interface to identify a network interface, network to identify a tenant network, segment to identify a tenant network segment, and load balancer to identify a load balancer machine or appliance in a data center.

[0034] Table 1

[0035]

[0036] Some embodiments utilize path prefixes to specify one of the optional parameters for imposing constraints, as further explained below. However, other embodiments may replace this method with another approach to use regular expressions to match or identify some prefixes. Therefore, not all embodiments of the present invention are limited to using hierarchical paths in a specified policy.

[0037] In some embodiments, the expression 210 for the received policy specifies one or more constraints on the operations that can be specified on the set of target resources of the policy. One example of a constraint is a value constraint, which limits the value of an attribute of a resource that is the target of the policy. In some embodiments, the value constraint includes an operator that is one of an include operator, an exclude operator, or an equality operator. Another example of a constraint is an entity instance count constraint, which limits the number of instances of a target resource (e.g., limiting the number of VPNs, routers, gateways, load balancers, connection sessions, firewall rules, etc.).

[0038] Yet another example is a related attribute constraint, which limits the value of a secondary attribute of a target resource that has a primary attribute defined by a value constraint. For example, a related attribute constraint can be used to define a constraint such as "If the destination of a transaction is a billing workload, then the allowed services are limited to HTTPS and SSH." Those of ordinary skill will recognize that other embodiments include other types of constraint expressions.

[0039] Figure 2 The illustrated policy 200 restricts access to destination machines in the destination group to http and https access. Specifically, the policy specifies the constraints to be applied at the edge gateway of the tenant T domain, as indicated by its path prefix 216. The constraints specify that when a message is addressed to the destination group VCENTER, the message (i.e., the access) should be allowed only if the protocol of the message is http or https (i.e., when the access uses the http or https protocol).

[0040] Figure 4 The diagram shows how, in some embodiments, Figure 2 This example illustrates a policy 200 being provided to a policy input processor. As shown, the policy 200 is provided within a CURL patch command 400, which begins with the CURL instruction "request PATCH\." Next, the policy name is provided as a URL, followed by an authorization header and a content type description specifying that the data is in JSON format. Finally, the policy 200 is provided as the data component of the CURL patch command.

[0041] Figure 5 Another example of a policy is shown. This policy 500 specifies that any communication rules specified can only specify an "allow" action at the edge gateway. This policy prevents administrators from defining rules that deny data messages at the edge gateway. This policy is used as the default firewall policy in a whitelist approach (no communication is allowed unless opened with an explicit firewall rule), which only allows administrators to specify firewall rules for open connections at the edge gateway.

[0042] Figure 6 The diagram illustrates a process 600 performed by the request processor 125 and the policy framework 100 to process an API related to SD resources in the SDDC. In some embodiments, the API is a hierarchical API that specifies one or more operations for one or more SD resources in the SDDC. Such a hierarchical API is further described in U.S. patent application Ser. No. 16 / 200,677, filed on November 27, 2018. U.S. patent application Ser. No. 16 / 200,677 is incorporated herein by reference.

[0043] In process 600, the request processor 125 first parses (at 605) the received hierarchical API into a set of one or more requests for one or more SD resources in the SDDC. In some embodiments, the received API may include not only different requests for different resources, but also multiple requests for a single SD resource. In some embodiments, the received API may include multiple different requests for only one SD resource. In some embodiments, each request specifies a single operation to be performed on the resource, while in other embodiments, the request may specify multiple operations to be performed on the resource.

[0044] After parsing the API into one or more requests, the request processor 125 calls the policy checking engine 115 to validate each request (i.e., specify whether each request satisfies all constraints in all policies applicable to the SD resources referenced in the API). Thus, at 610, the request processor 125 selects a parsed request from the received API. The request processor 125 then instructs (at 615) the policy checking engine 115 to identify one or more policies applicable to the selected request. Each request is associated with a resource in the resource hierarchy of the SDDC. As described above, in some embodiments, each resource can be a parent resource of several other child resources in the resource hierarchy.

[0045] At 615, the policy inspection engine 115 compares the set of attributes of the resource of the selected request with the target of the policy to determine whether the policy is applicable to the resource. Specifically, to identify a policy that is applicable to the resource of the selected request, the policy inspection engine 115 compares one or more attributes of the selected request (e.g., an identifier of the associated resource of the request) with one or more attributes specified in the target of each policy stored in the policy storage device 105 (e.g., a path prefix and a resource type) to identify a policy with a matching set of attributes (i.e., a set of attributes that matches the set of attributes of the selected request). For example, for an API request to adjust web access to an Outlook workload, the policy inspection engine 115 identifies the second, third, and fourth policies described above (for the Outlook workload, the web profile for the workload, and browser access for the workload) as applicable to the API request. In some embodiments, the policy storage device 105 stores policies using the same schema in which these policies are defined (e.g., using a schema as described above). Figure 2 、 4 Same pattern as described in 5).

[0046] After identifying an applicable policy, the policy inspection engine determines (at 620) whether the expression of the identified policy specifies a constraint requiring the selected request to be denied. To make this determination, the policy inspection engine compares a set of attributes of the selected request (e.g., data message flow attributes when the request relates to a forwarding operation or service operation on a data message flow between machines in the SDDC, deployment attributes when the request relates to the deployment of a machine or network element, etc.) with the attributes specified for the constraints in the expression of the applicable policy to determine whether the selected request violates the constraints of the policy. Thus, upon comparing the set of resource attributes of the selected request with the target of the policy to identify the applicability of the policy to the resource, the policy inspection engine 115 compares the set of attributes of the resource with the expression of the applicable policy to determine whether the request should be allowed or denied.

[0047] For example, when the API request requires the creation of a firewall rule, the policy inspection engine 115 will Figure 5 The policy 500 is identified as the applicable policy and then determines whether the firewall rule specifies an accept or deny action. When the firewall rule for the request specifies an accept action, the policy inspection engine determines that the request satisfies the constraints specified by the policy 500, but when the firewall rule specifies a deny action, the policy inspection engine determines that the request fails to satisfy the specified policy and will deny the request.

[0048] When the policy inspection engine 115 determines (at 620) that the selected request violates the constraints of the identified policy, it instructs (at 625) the API processing engine 125 to reject the API and return a notification to the source of the rejected API. In some embodiments, the process ends after the API processing engine 125 rejects the API. In other embodiments, the process 600 does not end after it determines that the API violates at least one policy. In these embodiments, the API processing engine 125 instructs the policy inspection engine 115 to validate each request in the received API so that it can provide a report to the API source to identify all policies violated by the rejected API.

[0049] When the policy checking engine 115 determines (at 620) that the selected request does not violate the constraints of the identified policy, it determines (at 630) whether any other policy in the policy repository 105 applies to the selected request. If so, the engine 115 selects (at 635) that policy and transitions back to 620 to determine whether the policy's expression specifies a constraint that the request violates. The process loops between 620-635 as long as the process can find a policy that applies to the request and has not yet been processed. The loop ends when the engine 125 identifies a policy with a constraint that the request violates, or when the engine completes its analysis of the policy that applies to the request.

[0050] When the policy checking engine 115 determines (at 630) that it has checked all policies applicable to the selected request, the engine notifies (at 640) the API processing engine 125 that the selected request does not violate any policies. Next, at 642, the API processing engine 125 determines whether the received API has any other parsed requests that have not yet been verified by the policy checking engine 115. If so, the API processing engine 125 selects (at 645) the next request and returns to 615 to instruct the policy checking engine 115 to verify the newly selected request (i.e., check whether the request violates any constraints of any policy applicable to the request).

[0051] When the API processing engine 125 determines (at 642) that the received API has no other parsed requests that have not been validated by the policy inspection engine 115, the API processing engine uses (at 650) one or more deployment engines (not shown) to persist the configuration changes required for the processed layered API(s) (i.e., to specify or modify previously specified configuration data for any resources affected by the API). These deployment engines specify or modify previously specified configuration data in configuration data storage(s) (not shown).

[0052] Once the configuration data has been persisted to the configuration data store(s), the API processing engine 125 returns a notification to the source of the API indicating that the API request has been processed. Next, at 660, the API processing engine instructs one or more resource managers 130 to perform the operations associated with the received request(s) in the API. In other embodiments, rather than being directed by the API processor 125, the deployment plug-in instructs the resource manager to distribute the new or modified configuration data set from the configuration data store(s) to the resources.

[0053] In these embodiments, in response to these notifications from the API processor or deployment plug-in, the resource manager then performs the operation(s) associated with the request(s) received in the API. As described above, the resource manager can perform its operations by directly interacting with data center resources (e.g., host computers) to define or modify desired resources (e.g., firewall service machines or modules), or indirectly through local and / or remote controllers that interact with data center resources to define or modify desired resources.

[0054] After 660 , the process 600 ends.

[0055] Many of the above features and applications are implemented as software processes, which 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 (one or more) 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 drives, EPROMs, and the like. Computer-readable media do not include carrier waves and electronic signals transmitted wirelessly or via wired connections.

[0056] In this specification, the term "software" refers to firmware residing in read-only memory or applications stored in magnetic storage devices that can be read into memory for processing by a processor. In addition, 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 is within the scope of the present invention. In some embodiments, when a software program is installed to operate on one or more electronic systems, the software program defines one or more specific machine implementations that perform the operations of the software program.

[0057] Figure 7 A computer system 700 is conceptually shown for implementing some embodiments of the present invention. The computer system 700 can be used to implement any of the hosts, controllers, and managers described above. Thus, it can be used to perform any of the processes described above. 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 700 includes a bus 705, processing unit(s) 710, system memory 725, read-only memory 730, permanent storage device 735, input device 740, and output device 745.

[0058] Bus 705 collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of computer system 700. For example, bus 705 communicatively connects processing unit(s) 710 with read-only memory 730, system memory 725, and permanent storage device 735.

[0059] From these various memory units, processing unit(s) 710 retrieves instructions to be executed and data to be processed in order to perform the processes of the present invention. The processing unit(s) may be a single processor or a multi-core processor in different embodiments. Read-only memory (ROM) 730 stores static data and instructions required by processing unit(s) 710 and other modules of the computer system. Persistent storage device 735, on the other hand, is a read and write memory device. This device is a non-volatile storage unit that stores instructions and data even when the computer system 700 is turned off. Some embodiments of the present invention use a mass storage device (such as a magnetic or optical disk and its corresponding disk drive) as permanent storage device 735.

[0060] Other embodiments use removable storage devices (such as floppy disks, flash drives, etc.) as permanent storage devices. Like permanent storage device 735, system memory 725 is a read and write memory device. However, unlike storage device 735, system memory is a volatile read and write memory, such as random access memory. 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 system memory 725, permanent storage device 735, and / or read-only memory 730. From these various memory units, processing unit(s) 710 retrieves instructions to be executed and data to be processed in order to perform the processes of some embodiments.

[0061] The bus 705 is also connected to input and output devices 740 and 745. Input devices enable a user to communicate information and select commands to the computer system. Input devices 740 include an alphanumeric keyboard and a pointing device (also known as a "cursor control device"). Output devices 745 display images generated by the computer system. Output devices include printers and display devices, such as cathode ray tubes (CRTs) or liquid crystal displays (LCDs). Some embodiments include devices such as touch screens that function as both input and output devices.

[0062] Finally, if Figure 7 As shown, bus 705 also couples computer system 700 to a network 765 via a network adapter (not shown). In this way, the computer can be part of a network of computers (such as a local area network ("LAN"), a wide area network ("WAN"), or an intranet), or a network of multiple networks (such as the Internet), and any or all components of computer system 700 can be used in conjunction with the present invention.

[0063] Some embodiments include electronic components, such as microprocessors, that store computer program instructions in a machine-readable or computer-readable medium (alternatively referred to as a computer-readable storage medium, a machine-readable medium, or a machine-readable storage medium). Some examples of such computer-readable media include RAM, ROM, compact disc read-only disk (CD-ROM), compact disc recordable disk (CD-R), compact disc rewritable disk (CD-RW), read-only digital versatile disk (e.g., DVD-ROM, dual-layer DVD-ROM), various recordable / rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD card, mini SD card, micro SD card, etc.), magnetic and / or solid-state hard drives, read-only and recordable A computer readable medium may store a computer program that is executable 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 produced by a compiler, and files including higher-level code that is executed by a computer, electronic component, or microprocessor using an interpreter.

[0064] Although the above discussion primarily refers to microprocessors or multi-core processors that execute software, some embodiments are performed 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 circuits themselves.

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

[0066] Although the present invention has been described with reference to many specific details, it will be appreciated by those skilled in the art that the present invention may be embodied in other specific forms without departing from the spirit of the invention. Therefore, it will be understood by those skilled in the art that the present invention is not limited by the foregoing illustrative details, but is defined by the appended claims.

Claims

1. A method of processing a request to perform an operation on a resource in a data center, the method comprising: Parsing a declarative API into a plurality of requests, wherein each request specifies at least one operation to be performed on at least one resource; For each parsed request: identifying at least one policy applicable to the request by comparing a set of attributes of the request to a set of attributes of a set of policies that impose constraints on operations specified for a resource; as well as determining whether the request violates the policy identified for the request; as well as The declarative API is rejected as an unpermitted API upon determining that at least one particular request violates a particular policy identified for the at least one particular request.

2. The method of claim 1, wherein the policies in the policy set are defined in a declarative format.

3. The method of claim 1, wherein the API is a hierarchical API that identifies resources at different hierarchical levels of the data center, and the policy set includes policies that impose constraints on operations specified for resources at different hierarchical levels of the data center. The method of claim 3 , wherein the resources at different hierarchical levels include workloads and service rules. 5 . The method of claim 3 , wherein the specific request violates the specific policy when the specific request violates a constraint specified by the specific policy for a specific resource associated with the specific request.

6. The method of claim 5, further comprising: Receive multiple strategies before parsing the hierarchical API, Each strategy includes: a target, which specifies a set of one or more data center resources to which the policy applies, and an expression specifying a constraint on an operation on the specified set of resources; and The received plurality of policies are stored in a storage device that is checked when processing a request for an operation associated with a resource. The method of claim 6 , wherein the received plurality of policies are expressed in a declarative format.

8. The method of claim 7, wherein the objectives of each policy include: The resource type of the specified resource collection, and A path prefix of the specified set of resources in a resource hierarchy of the data center is identified.

9. The method of claim 7, wherein the plurality of expressions for the received policy set comprises at least one of the following: value constraints that restrict the value of the attribute of the resource that is the target of the policy, and An entity instance count constraint that limits the number of instances of a target resource.

10. The method of claim 9, wherein the value constraint comprises an operator that is one of an inclusion operator, an exclusion operator, or an equality operator.

11. The method of claim 7, wherein the plurality of expressions for the received policy set comprises: a value constraint that restricts the value of a first attribute of a resource that is the target of the policy, and A related attribute constraint restricts a value of a second attribute of a target resource.

12. A method as claimed in claim 3, wherein the specific resource specified by the specific request is at a specific level in the hierarchical levels, and wherein the comparison includes comparing the attribute set of the specific request with the attribute set of the policy specified for the resource defined at the specific level or a higher level in the hierarchical levels.

13. The method of claim 12, wherein the specific resource is a sub-resource of other resources, and the policy for the specific resource is specified for the other resources.

14. The method of claim 1 , wherein each of the plurality of requests is a request to create or modify a forwarding rule for forwarding a data message, a request to create or modify a service rule for performing a service operation on a data message, or a request to deploy or modify a machine or network element in the data center.

15. The method of claim 1, wherein The method is implemented by the policy framework, Each policy specifies a resource type, which identifies the type of resource to which the policy applies. Including the resource type in each policy allows new resource types to be added to the policy framework without reprogramming the policy framework.

16. The method of claim 1, Wherein identifying the at least one policy for each request comprises: Identify all policies that apply to the request, and A determination is made as to whether the request satisfies all policies identified for the request.

17. A non-transitory machine-readable medium storing a program for processing a request to perform an operation on a resource in a data center, the program comprising a set of instructions for: Parsing a declarative API into a plurality of requests, wherein each request specifies at least one operation to be performed on at least one resource; For each parsed request: identifying at least one policy applicable to the request by comparing a set of attributes of the request to a set of attributes of a set of policies that impose constraints on operations specified for a resource; as well as determining whether the request violates the policy identified for the request; upon determining that at least one particular request violates a particular policy identified for the at least one particular request, rejecting the declarative API as an unpermitted API; as well as After determining that none of the parsed requests violates any of the identified policies, the declarative API is authorized for execution.

18. The non-transitory machine-readable medium of claim 17, wherein the API is a hierarchical API that identifies resources at different hierarchical levels of the data center, wherein the program further comprises a set of instructions for: Receive multiple strategies before parsing the hierarchical API, Each strategy includes: a target, which specifies a set of one or more data center resources to which the policy applies, and an expression specifying a constraint on an operation on the specified set of resources; as well as The received plurality of policies are stored in a storage device that is checked when processing a request for an operation associated with a resource.

19. The non-transitory machine-readable medium of claim 18, wherein the received plurality of policies are expressed in a declarative format.

20. The non-transitory machine-readable medium of claim 18, wherein the objectives of each policy include: The resource type of the specified resource collection, and A path prefix of the specified set of resources in a resource hierarchy of the data center is identified.

21. The non-transitory machine-readable medium of claim 18, wherein the plurality of expressions for the received policy set include at least one of: value constraints that restrict the value of the attribute of the resource that is the target of the policy, and An entity instance count constraint that limits the number of instances of a target resource.

22. The non-transitory machine-readable medium of claim 18, wherein the plurality of expressions for the received policy set include: a value constraint that restricts the value of a first attribute of a resource that is the target of the policy, and A related attribute constraint restricts a value of a second attribute of a target resource.

23. A non-transitory machine-readable medium as described in claim 18, wherein the specific resource specified by the specific request is at a specific level in the hierarchical levels, and wherein the comparison includes comparing the attribute set of the specific request with the attribute set of the policy specified for the resource defined at the specific level or a higher level in the hierarchical levels.

24. An electronic device for processing a request to perform an operation on a resource in a data center, comprising: A collection of processing units; as well as A machine-readable medium storing a program, which, when executed by at least one processing unit, implements the method according to any one of claims 1 to 16.

25. A system for processing requests to perform operations on resources in a data center, comprising means for implementing the method according to any one of claims 1-16.

26. A computer program product for processing a request to perform an operation on a resource in a data center, comprising instructions which, when executed by a computer, cause the computer to perform the method according to any one of claims 1 to 16.

Images