WO2017095391A1

WO2017095391A1 - Label management

Info

Publication number: WO2017095391A1
Application number: PCT/US2015/063123
Authority: WO
Inventors: Joon-Myung Kang; Jeongkeun Lee; Vasudevan NAGENDRA
Original assignee: Hewlett Packard Enterprise Development Lp
Priority date: 2015-12-01
Filing date: 2015-12-01
Publication date: 2017-06-08

Abstract

Example implementations relate to managing labels. In an example, a device implements a label management system in a network. The device may include a label manager to store multiple label definitions in a database. Each label definition can define a label and include information about the label, each label representing a potential attribute of an endpoint in the network. The device may also include a label tree manager. The label tree manager may receive, from an external entity, a label tree definition specifying a relation between multiple specified labels stored in the database, receive information about the specified labels from the label manager, generate a set of policies using the received information and the relation, and send the set of policies to a policy management system that monitors policy compliance of endpoints in the network.

Description

LABEL MANAGEMENT

Background

[0001 ] Networks can include a plurality of entities connected by communication links, and can be used to connect people, provide services (e.g., internally and/or externally via the Internet and/or intranet), and/or organize information, among other activities. These entities may be referred to as endpoints in the network, and may be physical or virtual devices or resources accessing the network, communicating via the network, and/or providing services on the network. Managing and enforcing network policies (e.g., access control, security, service function chains, etc.) on these endpoints can be a difficult and challenging task.

Brief Description of the Drawings

[0002] Figure 1 illustrates an example environment with devices for implementing the techniques described herein, according to an example.

[0003] Figure 2 illustrates a flow chart of example processes for implementing the techniques described herein, according to an example. [0004] Figure 3 illustrates a flow chart of example processes for implementing the techniques described herein, according to an example.

[0005] Figure 4 illustrates an example label definition, according to an example.

[0006] Figures 5(a) and 5(b) illustrate example label trees, according to examples.

[0007] Figure 6 illustrates a flow chart of example processes for implementing the techniques described herein, according to an example.

[0008] Figure 7 illustrates a flow chart of an example process for implementing the techniques described herein, according to an example.

[0009] Figure 8 illustrates a flow chart of an example process for implementing the techniques described herein, according to an example.

[0010] Figure 9 illustrates an example computer for implementing the techniques described herein, according to an example.

Detailed Description

[001 1 ] Example implementations relate to an automated technique for extracting network policy endpoint attribute information from various sources and creating logical labels representing the attributes. Relations between labels are captured to assist with network policy analysis and composition. Changes to endpoint attributes are monitored and tracked. In an example, a device implements a label management system in a network. The device may include a label manager to store multiple label definitions in a database. Each label definition can define a label and include information about the label, each label representing a potential attribute of an endpoint in the network. The device may also include a label tree manager. The label tree manager may receive, from an external entity, a label tree definition specifying a relation between multiple specified labels stored in the database, receive information about the specified labels from the label manager, generate a set of policies using the received information and the relation, and send the set of policies to a policy

management system that monitors policy compliance of endpoints in the network.

[0012] A trend in policy-driven cloud/IT/network management is using logical labels (e.g., tags, metadata) to define a group of policy endpoints that a given policy needs to be applied to. A policy is a rule or behavior specified for certain devices on the network. For instance, example policies include access control of communications, quality of service (QoS) requirements, and network services (which may form a part of a required service function chain). This trend toward logical labels is in contrast to a more traditional approach of using specific endpoint identifiers (e.g., IP address/subnet, MAC address, device ID, resource ID) for policy management and compliance, which ties a given policy to low-level specifics on a per-device scale, which can create significant overhead as the number of network endpoints and the number of policies grow. In contrast, writing policies in terms of labels keeps the policies high-level (e.g., able to be applied to groups of endpoints rather than single endpoints), reusable, and portable.

[0013] Example systems and techniques for label-based policy implementation are described in PCT/US2014/064394, filed on November 6, 2014 and entitled "Network Policy Graphs", and PCT/US2015/041546, filed on July 22, 2015 and entitled "Providing a Composite Network Policy", both of which are hereby incorporated by reference. The techniques described herein expand upon this work and enable label management in an automated fashion.

[0014] FIG. 1 depicts an example environment 100 in which the techniques described herein may be implemented, according to examples. The environment may include external entities 1 10, which may be users, applications, or a high-level network management system, for example. These entities may communicate with the label management system 120 via user interfaces or application programming interfaces, for example. The label management system 120 may include a label manager 121 , a label tree manager 122, an endpoint group (EPG) manager 123, and a database 124. The label management system may communicate with an infrastructure policy management system 130, which may manage and check compliance with network policies. The policy management system 130 may gather data from various data sources 140.

[0015] The devices implementing the components of environment 100 may be connected via a network and may include one or more controllers and one or more machine-readable storage media. A controller may include a processor and a memory for implementing machine readable instructions. The processor may include at least one central processing unit (CPU), at least one semiconductor-based microprocessor, at least one digital signal processor (DSP) such as a digital image processing unit, other hardware devices or processing elements suitable to retrieve and execute instructions stored in memory, or combinations thereof. The processor can include single or multiple cores on a chip, multiple cores across multiple chips, multiple cores across multiple devices, or combinations thereof. The processor may fetch, decode, and execute instructions from memory to perform various functions. As an alternative or in addition to retrieving and executing instructions, the processor may include at least one integrated circuit (IC), other control logic, other electronic circuits, or combinations thereof that include a number of electronic components for performing various tasks or functions.

[0016] The controller may include memory, such as a machine-readable storage medium. The machine-readable storage medium may be any electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions. Thus, the machine-readable storage medium may comprise, for example, various Random Access Memory (RAM), Read Only Memory (ROM), flash memory, and combinations thereof. For example, the machine-readable medium may include a Non-Volatile Random Access Memory (NVRAM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a storage drive, a NAND flash memory, and the like. Further, the machine-readable storage medium can be computer-readable and non- transitory. Additionally, one or more machine-readable storage media separate from the one or more controllers may also be included.

[0017] Label management system 120 provides northbound interfaces for managing labels, label trees, and endpoint groups. It also uses southbound interfaces for creating/updating/getting/deleting/monitoring policies and obtaining infrastructure data from an existing infrastructure policy management system 130.

[0018] As used herein, an "endpoint" is a smallest unit for policy enforcement. Example endpoints include a network device, port, virtual machine, or container. As used herein, a "label" is a membership predicate, which is a Boolean valued function representing an endpoint attribute. Example endpoint attributes include owner, network name, placement location, security status, etc. An attribute can be static (e.g., virtual machine ownership) or dynamic (e.g., security status, virtual machine location). As used herein, an "endpoint group" is a set of endpoints that satisfy a membership predicate (i.e., Boolean expression) defined over one or more labels. For example, an endpoint group defined as "Tenant:Lee & Location:Zone-1 & Security:Normal" may refer to a set of virtual machines owned by Tenant 'Lee', placed in 'Zone-1 ', and with a 'Normal' security status. Any endpoints in the network with all of those attributes would be a member of that endpoint group.

[0019] A label for an endpoint attribute may be represented as a combination of key and value (key:value), where key is a type of the end point attribute and value is the particular value of that end point attribute. For example, for "Tenant:Lee", Tenant is a key and Lee is a value. A label tree captures hierarchical relations between labels. FIG. 5(a) shows an example of a label tree 510 for the endpoint attribute LOCATION. Label tree 510 shows how various values of the same label type are related. The root node of the tree, LOCATION, is considered to be the 'key' attribute. A name of a root node is unique in the label namespace. Non-root nodes are 'value' attributes of the tree root. All nodes except LOCATION are non-root nodes. Leaf nodes are the most basic elements of the tree and are the membership predicates actually assigned to endpoints. CAMPUS 1 , CAMPUS 2, EAST, ZONE 1 , ZONE 2, ZONE 3, DC1 , DC2, and PRIVATE CLOUD are all leaf nodes in tree 510.

[0020] Non-leaf and non-root nodes are a composite predicate (i.e., a Boolean OR) of all of its descendant leaf labels. Thus, a pair of labels with ascendant-descendent relationship can overlap. PUBLIC CLOUD and WEST are non-leaf and non-root nodes. Any labels that do not have a parent-child relationship (i.e., siblings) are mutually exclusive and thus cannot be

simultaneously 'true' for any endpoint. For example, ZONE 1 , ZONE 2, and ZONE 3 are mutually exclusive, meaning an endpoint cannot exist in more than one zone simultaneously.

[0021 ] Inter-tree label mappings capture relations between two labels defined in different trees. For example, if the virtual machines of Tenant Lee are placed in Zone-1 , this placement relationship can be represented as a mapping between the Tenant:Lee label and the Location:Zone-1 label.

[0022] External entities 1 10 use the label management system 120 via the northbound interface for creating/updating/getting/deleting labels, label trees, and label policies. The external entities 1 10 can be users (e.g., administrator, application developers, etc.) third party applications, and high- level management systems (Network Management System (NMS), Operations Support System (OSS), or Business Support System (BSS)).

[0023] The infrastructure policy management system 130 provides policy- as-a-service across a collection of infrastructure services (i.e., data sources 140) in order to offer governance and compliance for dynamic infrastructure. An example infrastructure policy management system is OpenStack Congress, which provides an open-source framework that works over diverse cloud services (e.g., application, network, compute, and storage) running in

OpenStack infrastructure. It also provides policy enforcement for cloud services. Congress uses Datalog (a SQL-like programming language) as a policy language and uses table format for storing data and specifying relationships.

[0024] OpenStack Congress obtains states of the cloud services from various OpenStack services (i.e., data sources 140), such as Neutron, Nova, and Swift. Congress monitors these system states received from the data sources 140 and stores the results in tables. Congress can also check if the current system states abides by certain policies. For example, a policy may state to report an error if a virtual machine is connected to the Internet without being a part of an existing security group called "secure_private_VM". To implement this policy, Congress may create a table error_secure which has one column (vm) if the following conditions are met. First, it monitors and gets a table nova:servers which has vm, name, host, status, tenantjd, user_id, image_id, and flavorjd. Second, it defines one policy "connected_to_internet" which can determine if the vm is connected to the Internet using the given port. Finally, it defines another policy "not port_security_group" which can determine if the port is a member of security group "secure_private_VMs".

[0025] OpenStack Congress is used herein as an example of an infrastructure policy management system 130 and Datalog as an example policy language generated from label definitions and label tree definitions. However, the description and claims are not limited to these examples and any kind of policy management system and policy language may be used.

[0026] FIG. 2Error! Reference source not found, shows an example of processes 200 for creating or updating a label and label tree, and getting a label tree. External entities 1 10 may initially provide the label manager 121 , which manages the label namespace, with a label definition that declares one or more labels and additional information about the data sources/tables/attributes associated with that label. The label manager 121 stores the label definition in database 124.

[0027] External entities 1 10 can then provide the label tree manager 122 with a label tree definition that specifies a hierarchical relation between one or more labels defined in the label definitions stored in the database 124. The label tree manager builds infrastructure policies in the Datalog language using the information on data sources/tables/attributes specified in the label definitions and based on the hierarchical relation. Label tree manager 122 then requests the infrastructure policy management system 130 to create/update the infrastructure policies. The infrastructure policy management system 130 then monitors system states from data sources 140 and stores them in a table format.

[0028] FIG. 3 shows an example of processes 300 for getting a label tree. External entities 1 10 may request a label tree to the label tree manager 122 using a tree 'key' attribute. The label tree manager 122 requests state data from the infrastructure policy management system 130 and builds a label tree using the collected data. Because state data is dynamically updated by infrastructure policy management system 130 according to changes received from data sources 140, the label tree related to the data is also adaptively changed since any later requested tree will reflect the updated system state data.

[0029] For illustration purposes, example label definitions and label tree definitions will now be described. Of course, other definitions and models for implementing these concepts may also be used, and the claims and description are not limited to these examples.

[0030] FIG. 4 illustrates an example label definition, which can specify how to capture data from given data sources under certain conditions. A 'label definition' in Extended Backus-Naur Form (EBNF) is provided, as well as an example from OpenStack Congress written in Datalog. In the left column of 400, label_definition is defined as KEY and VALUE. A set of key names is followed by a keyword KEY and a set of value definitions is followed by a keyword VALUE. The value definition is composed of 5 properties: NAME, KEY, VALUE, DATA_SOURCE, and CONDITION. NAME is a value name and KEY is a key name for this value from the set of key names. DATA_SOURCE specifies the data sources (datasource_name), their tables (table_name) and attributes (attribute) in the tables which contain all collected state data from the infrastructure policy management system 120. VALUE specifies a real value with one of the attributes in the data sources. CONDITION defines the necessary conditions to extract the final result using the given data source tables and attributes specified in DATA_SOURCE. To specify conditions, logical operators (==, !=, >, <, >=, <=) are used between attributes.

[0031] The right column in 400 shows an example of three 'keys' and four 'values' of label definitions using data sources and tables available in

OpenStack Congress. For example, the first line represents three key names: APPLICATION, TENANT, LOCATION. Four values follow, each specified within curly brackets (i.e., {...}). The first example defines a value "APP_NAME". The key of this value is APPLICATION by the property NAME. In the

DATA_SOURCE, it uses two data sources with associated table and attribute information: (1 ) a data source murano, a table objects, and attributes objectjd and type, and (2) a data source murano, a table properties, and attributes ownerjd, value, and name. In the VALUE, the attribute 'value' from the table murano:properties is used for a real value. In the CONDITION, three conditions are specified that must be met: objectjd is equal to ownerjd, name is equal to a string "name", and type is not equal to a string "Library".

[0032] The following table represents a label tree definition written in

EBNF and an example for LOCATION.

Label tree definition (EBNF) Example

label_tree -> key@values; LOCATI O N @ AVAI LABI LITY_ZON E, H OST values -> value;

values -> values, value;

[0033] In the left column, labeljxee is defined as one of the keys and a set of values in the label definition, which order means a hierarchy level (parent- child relationship). In the definition, value name is used to specify a label tree rather than value details. Thus, the label management system can automatically builds a label tree using the key and values. When the label tree is given, the label tree manager 122 retrieves label definitions included within the tree from label manager 121 and converts the label tree definition to infrastructure policy language (e.g. Datalog) for the infrastructure policy management system 130.

[0034] In the right column, the example shows that a tree LOCATION can be built using a value AVAI LAB I L ITY_ZON E and HOST, which have a parent- child relationship. The label tree manager 122 may generate Datalog using label definitions of AVA I LAB I L I TY_ZO N E and HOST, as shown in FIG. 4.

Because each value has its key name in the label definition, the hierarchical relationship between all values which have a same key name can be automatically inferred.

[0035] The below table shows generated Datalog for

AVAI LAB I L ITY_ZON E (P1 ) and HOST (P2) in accordance with the given label relationship definition. These may be stored as policies via the Congress API and Congress may keeps the tables up to date based on data source changes.

[0036] The following table shows sample stored data by the policy P1 and Error! Reference source not found, shows a sample stored data by the policy P2.

KEY AVAILABILITY ZONE updated time LOCATION AZl 2015-09-09 01:04:17

LOCATION AZ2 2015-09-09 01:04:17

[0037] The following table shows sample stored data by the policy P2.

[0038] When the tree name/key LOCATION is given, the label tree 520 shown in FIG. 5(b) is expected based on the data in the above tables:

AVAILABILITY_ZONE and HOST. As described, label management system 120 is able to build this label tree in an automated fashion using the system data obtained from infrastructure policy management system 130. Specifically, as shown in the table below, label tree manager 122 generates the LOCATION table by joining the AVA I LAB I L I TY_ZO N E table and the HOST table.

[0039] Label tree manager 122 then builds a label tree as shown in FIG. 5(b) using the generated table and returns the LOCATION tree 520Error! Reference source not found..

[0040] Endpoints can be assigned labels dynamically at runtime, causing them to move from one endpoint group to another. For example, a server that was assigned the label "normal" could subsequently be relabeled "quarantined" when a network monitor detects the server issuing a DNS query for a known malicious Internet domain. The runtime system needs to perform the operation of looking up and applying the correct rules for each EP depending on its current EPG membership. To facilitate this, a list of endpoints that satisfy given endpoint group definitions (e.g., a membership predicate defined over a set of labels) may be maintained. Using the relations captured in the label trees and inter-tree mappings, individual policies can be automatically, proactively, and scalably composed.

[0041 ] FIG. 6 shows an example of processes 600 for creating/updating an endpoint group definition and generating infrastructure policies based thereon. External entities 1 10 may initially provide an endpoint group definition to the endpoint group manager 123. Prior to describing the processes 600, an example with example data will be described.

[0042] The following tableError! Reference source not found.

represents endpoint group definition examples written in a Disjunctive Normal Form (DNF) of Boolean expression of a set of labels (key:value).

Example

EPG_1: TENANT:admin & LOCATION :AZl

EPG_2: (TENANT:admin & LOCATION :AZl) | (TENANT:admin & LOCATION :AZ2) | (TENANT:Lee & LOCATION :AZ3)

EPG_3: (TENANT:admin & LOCATION :AZl) | (TENANT:Kang & LOCATION :HOST2)

[0043] The first example means to check if any endpoint is a member of a tenant admin and is located on the location AZ1 . The second example means to check if any endpoint is a member of a tenant admin and located on the AZ1 or AZ2, or a member of a tenant Lee and located on the location AZ3. The third example means to check if any endpoint is a member of a tenant admin and located on the AZ1 , or a member of the tenant Kang and located on the HOST2. [0044] Then, the EPG definition is converted to a set of infrastructure policies (e.g., Datalog) using the label definitions. The following table shows an example of Datalog automatically generated from the EPG_1 in the previous table, in case that the external entities want to use a vm as endpoint.

now(time_t)

[0045] A table EPG_1 is created for matching 'vm' (EP) and the given Boolean expression. The EPG manager 123 creates or updates the policies via an application programming interface to the infrastructure policy management system 130. The infrastructure policy management system periodically monitors the data sources 1 10 and keeps up-to-date system states.

Specifically, the EPG manager 123 generates Datalog as follows:

(keystone:tenants(id=tenant_id, name=tenant_name), equal (tenant_name, "Lee")) from TENANT:Lee by using the label definition.

[0046] The following are an example of tables showing stored data for EPG_1 , EPG_2, and EPG_3.

EPG 1 EPG_2 EPG 3

VM UPDATED_T!ME

VM1 20 5-09-0901:05: 7

VM2 2015-09-0901:10:16

VM5 2015-09-0901:15:27

V 7 2015-09-0901:25:47 [0047] Based on the stored policies, endpoint-to-endpoint group mappings may be extracted, and mapping changes may be detected and adapted to. This is illustrated in FIG. 6.

[0048] FIG. 6 shows a flowchart of processes 600 for mapping the endpoints-to-endpoint groups using the endpoint group definition. The infrastructure policy management system 130 periodically monitors up-to-date states from data sources 1 10. If an endpoint is created or its attributes are updated (label changes), the infrastructure policy management system 130 classifies the endpoint into the table that implements the exact-matching endpoint group definition (label predicate). Then, the EPG manager 123 retrieves all endpoints from the updated table. The endpoints are mapped to the matching endpoint group. By repeating this process on a periodic basis, the system can maintain all endpoint-to-endpoint group mappings automatically.

[0049] FIGS. 7 and 8 illustrate example methods to implement the techniques described herein, according to various examples. Methods 700, 800 may be performed by a computing device, computer, server, or the like, such as a device implementing label management system 120 or computer 910.

Computer-readable instructions for implementing methods 700, 800 may be stored on a computer readable storage medium.

[0050] Turning to method 700, at 701 a label tree definition may be received, such as from an external entity. The label tree definition may specify a relation between multiple labels. At 702, information about the labels specified in the label tree definition may be obtained. The information may be obtained by label tree manager 122 from database 124, and may include information about data sources, tables, and attributes. The information may be provided by label manager 121 . At 703, label tree manager 122 may generate a set of policies using the obtained information and the relation. The policies may be generated in a language understandable by infrastructure policy management system 130. At 704, label tree manager 122 may send the set of policies to infrastructure policy management system 130, such as via an application programming interface.

[0051 ] Turning to method 800, at 801 an endpoint group definition specifying membership within the endpoint group based on a set of labels may be received. At 802, endpoint group manager 123 may obtain information about the set of labels, such as from database 124. At 803, endpoint group manager 123 may generate a set of policies using the information. At 804, endpoint group manager 123 may send the set of policies to the infrastructure policy management system 130.

[0052] FIG. 9 illustrates a computer to implement the techniques described herein, according to an example. The computer may include one or more controllers and one or more machine-readable storage media.

[0053] Processor 920 may be at least one central processing unit (CPU), at least one semiconductor-based microprocessor, other hardware devices or processing elements suitable to retrieve and execute instructions stored in machine-readable storage medium 930, or combinations thereof. Processor 920 can include single or multiple cores on a chip, multiple cores across multiple chips, multiple cores across multiple devices, or combinations thereof. Processor 920 may fetch, decode, and execute instructions 932-936 among others, to implement various processing. As an alternative or in addition to retrieving and executing instructions, processor 920 may include at least one integrated circuit (IC), other control logic, other electronic circuits, or

combinations thereof that include a number of electronic components for performing the functionality of instructions 932-936. Accordingly, processor 920 may be implemented across multiple processing units, and instructions 932-936 may be implemented by different processing units in different areas of computer 910.

[0054] Machine-readable storage medium 930 may be any electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions. Thus, the machine-readable storage medium may comprise, for example, various Random Access Memory (RAM), Read Only Memory (ROM), flash memory, and combinations thereof. For example, the machine-readable medium may include a Non-Volatile Random Access Memory (NVRAM), an Electrically Erasable Programmable Read-Only Memory

(EEPROM), a storage drive, a NAND flash memory, and the like. Further, the machine-readable storage medium 930 can be computer-readable and non- transitory. Machine-readable storage medium 930 may be encoded with a series of executable instructions for managing processing elements.

[0055] The instructions 932-936 when executed by processor 920 (e.g., via one processing element or multiple processing elements of the processor) can cause processor 920 to perform processes, such as described above, and/or variations and portions thereof. Instructions 932-936 will now be briefly described, which description should be read in light of the description of the previously described processes.

[0056] Send/receive instructions 932 may enable computer 910 to receive a label tree definition specifying a relation between multiple labels. Each label definition may define a label and include information about the label. Each label may represent a potential attribute of an endpoint in the network. Label instructions 934 may cause processor 920 to obtain information about the labels. The information may include data sources, attributes, and tables.

Policy instructions 936 may cause processor 920 to generate a set of policies using the obtained information and the relation specified in the label tree definition. Send/receive instructions 932 may allow the computer 910 to send the set of policies to a policy management system that monitors policy compliance of endpoints in the network. The policy management system may track endpoint state relative to the set of policies.

[0057] In the present disclosure, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration how a number of examples of the disclosure can be practiced. These examples are described in sufficient detail to enable those of ordinary skill in the art to practice the examples of this disclosure, and it is to be understood that other examples can be used and that process, electrical, and/or structural changes can be made without departing from the scope of the present disclosure.

[0058] As used herein, "logic" may be an alternative or additional processing resource to perform a particular action and/or function, etc., described herein, which includes hardware, e.g., various forms of transistor logic, application specific integrated circuits (ASICs), etc., as opposed to computer executable instructions, e.g., software firmware, etc., stored in memory and executable by a processor. Further, as used herein, "a" or "a number of something can refer to one or more such things. For example, "a number of widgets" can refer to one or more widgets. Also, as used herein, "a plurality of something can refer to more than one of such things.

[0059] The above specification, examples and data provide a description of the method and applications, and use of the system and method of the present disclosure. Since many examples can be made without departing from the spirit and scope of the systems and methods of the present disclosure, this specification merely sets forth some of the many possible embodiments, configurations, and implementations.

Claims

What is claimed is:

1 . A device implementing a label management system in a network, comprising:

a label manager to store multiple label definitions in a database, each label definition defining a label and including information about the label, each label representing a potential attribute of an endpoint in the network; and

a label tree manager to:

receive, from an external entity, a label tree definition specifying a relation between multiple specified labels stored in the database,

receive information about the specified labels from the label manager,

generate a set of policies using the received information and the relation, and

send the set of policies to a policy management system that monitors policy compliance of endpoints in the network.

2. The device of claim 1 , wherein the label tree manager is to store the label tree definition in the database.

3. The device of claim 1 , wherein the label manager is to receive the label definitions from external entities.

4. The device of claim 3, wherein the external entities comprise at least one of a user, an application, and a network management system.

5. The device of claim 1 , wherein the label tree manager is to generate the set of policies in a programming language understandable by the policy management system.

6. The device of claim 5, wherein the policy management system is to maintain a current state of endpoints in the network in table format according to the set of policies.

7. The device of claim 6, wherein the label tree manager is to: receive a request for the label tree from an external entity;

request state data for the requested label tree from the policy management system;

receive state data for the requested label tree from the policy management system;

generate a label tree instance based on the received state data; and send the label tree instance to the external entity.

8. The device of claim 7, wherein the received state data comprises a table.

9. The device of claim 8, wherein the device is to build the label tree instance by joining multiple received tables together.

10. The device of claim 1 , comprising an endpoint group manager to: receive an endpoint group definition from an external entity, the endpoint group definition specifying a membership predicate defined over a set of labels; receive second information about the set of labels from the label manager;

generate a second set of policies using the received second information; send the second set of policies to the policy management system; and store the endpoint group definition in the database.

1 1 . The device of claim 10, wherein the policy management system is to maintain a current state of endpoints in the network in table format according to the second set of policies.

12. A method for label management, comprising, by a processor: receiving a label tree definition specifying a relation between multiple labels, each label definition defining a label and including information about the label, each label representing an attribute that an endpoint in a network may have;

obtaining information about the labels from a database;

generating a set of policies using the obtained information and the relation; and sending the set of policies to a policy management system that monitors policy compliance of endpoints in the network.

13. The method of claim 12, comprising maintaining, by the policy management system, a current state of endpoints in the network according to the set of policies.

14. The method of claim 12, comprising:

receiving an endpoint group definition from an external entity, the endpoint group definition specifying membership within the endpoint group based on a set of labels;

obtaining second information about the set of labels from the database; generating a second set of policies using the received second information; and

sending the second set of policies to the policy management system.

15. A non-transitory computer-readable storage medium storing instructions for label management that, when executed by a processor, cause the processor to:

receive a label tree definition specifying a relation between multiple labels, each label definition defining a label and including information about the label, each label representing a potential attribute of an endpoint in a network; obtain information about the labels, the information including data sources, attributes, and tables; generate a set of policies using the obtained information and the relation specified in the label tree definition; and

send the set of policies to a policy management system that monitors policy compliance of endpoints in the network, the policy management system to track endpoint state relative to the set of policies.