Patent Publication Number: US-2022239635-A1

Title: Sharing of firewall rules among multiple workloads in a hypervisor

Description:
BACKGROUND 
     Multiple workloads often run on a single hypervisor on a host computing machine. A distributed firewall may be distributed across the multiple workloads on the host and enforce rules close to the source of traffic for the workloads. Each individual workload may have its own copy of firewall rules that are stored in the hypervisor kernel to enforce different policies, such as a security policy. Often, multiple workloads on the same hypervisor have some common firewall rules in their own copy of the rules. This may be because the workloads are executing similar functionality on the same hypervisor. For example, a company may put workloads that are performing the same or similar functions on a single host. Even though there are common firewall rules, the distributed firewall stores a separate set of firewall rules for each workload. This consumes a large amount of memory in the hypervisor, which may limit the number of firewall rules that a hypervisor can support. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  depicts a simplified system for implementing a distributed firewall according to some embodiments. 
         FIG. 2  depicts a simplified flowchart of a method for processing firewall rules according to some embodiments. 
         FIG. 3A  shows an example of a rules table according to some embodiments. 
         FIGS. 3B to 3D  depict examples of index tables according to some embodiments. 
         FIG. 4  depicts a simplified flowchart of a method for processing packets using a firewall according to some embodiments. 
     
    
    
     DETAILED DESCRIPTION 
     In the following description, for purposes of explanation, numerous examples and specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. Some embodiments as expressed in the claims may include some or all of the features in these examples, alone or in combination with other features described below, and may further include modifications and equivalents of the features and concepts described herein. 
     A hypervisor on a host computing device receives a copy of firewall rules for a group of workloads running on that hypervisor. The hypervisor may store a single copy of the firewall rules in the hypervisor for the group. Each workload may have an associated set of firewall rules where different workloads may apply a different set of firewall rules. Instead of storing a distinct copy of the firewall rules for each workload, the hypervisor stores a list of references to the firewall rules in an index table for each workload. The index table includes references to rules in a rules table. For example, a first index table for a first workload may include a first set of references that reference a first set of rules in the rules table and a second index table for a second workload may include a second set of references that reference a second set of rules in the rules table. The first set of references and the second set of references may include different references to rules, such as the first set of references may reference rules R1, R2, and R3, and the second set of references may reference rules R1, R3, and R5. 
     The use of the index tables allows the hypervisor to save memory. For example, storing only a single copy of the rules for the firewall rules used by the group of workloads eliminates the memory needed to store a distinct copy of firewall rules for each workload. Storing an index table for each workload may use a much smaller amount of memory than storing the distinct copy of rules for each workload. Using less memory provides some advantages, such as the use of less memory to store distinct copies of rules for each workload may allow the hypervisor to store a larger amount of rules in the rules table. 
     System Overview 
       FIG. 1  depicts a simplified system  100  for implementing a distributed firewall according to some embodiments. Hosts  102  may include workloads  106 - 1  to  106 -N. Workloads may refer to virtual machines that are running on a respective host, but this is one example of a virtualized computing instance or compute node. Any suitable technology may be used to provide a workload. Workloads may include not only virtual machines, but also containers (e.g., running on top of a host operating system without the need for a hypervisor or separate operating system or implemented as an operating system level virtualization), virtual private servers, client computers, etc. The workloads may also be complete computation environments containing virtual equivalents of the hardware and software components of a physical computing system. Also, as used herein, the term hypervisor may refer generally to a software layer or component that supports the execution of multiple workloads including system-level software that supports name space containers. 
     Workloads  106 - 1  to  106 -N may send and receive packets through virtual network interface cards (VNIC)  116 - 1  to  116 -N. The packets may be sent through a virtual switch  112  in hypervisor  104  to a physical network interface card (PNIC) in hardware  114 . Then, packets are routed through physical network  120 . Also, packets are received from physical network  120  at the PNIC, and sent through virtual switch  112  to VNICs  116  of workloads  106 . 
     Management platform  118  may be a platform that manages the virtual networks on host computing machines  102 . For example, management platform  118  may centrally manage firewall rules that are distributed to different hosts  102 . 
     A local controller plane (LCP)  120  may be a process that is running on hypervisor  104 . LCP  120  receives the firewall rules for workloads  106  from management platform  118 . For example, LCP  120  interacts with management platform  118  to retrieve the firewall rules. In some embodiments, LCP  120  is running in the user space of hypervisor  104 ; however, the implementation of LCP  120  may be different. LCP  120  processes the firewall rules to build rules table  124  and index tables  126 - 1  to  126 -N, the processing of which will be described in more detail below. 
     Firewall manager  122  manages the configuration of the distributed firewall in hypervisor  104 . For example, firewall manager  122  stores a central copy of all firewall rules in the memory of hypervisor  104 , such as in a rules table  124 . The structure and use of rules table  124  will be described in more detail below. Although LCP  120  and firewall manager  122  are described as being separate components, other configurations may be used, such as functions of both may be combined or distributed to other entities. 
     Instances of firewalls  110 - 1  to  110 -N are configured for each respective workload  106 - 1  to  106 -N. For example, each instance of distributed firewall  110  may be enforced in between VNIC  116  and virtual switch  112 . However, firewall  110  may be situated at any point in a path of packets, such as at VNIC  116 , or anywhere in between workload  106  and virtual switch  112 . Firewall  110  intercepts packets sent from VNIC  116  before they reach virtual switch  112  and also intercepts packets from virtual switch  112  before they reach VNIC  116 . Each respective workload  106  may have an associated firewall situated between VNIC  116  and virtual switch  112  although firewalls  110  may be placed at other positions. 
     Firewalls  110 - 1  to  110 -N store index tables  126 - 1  to  126 -N, respectively. Each index table  126  references specific firewall rules that apply to the respective workload  106 . Those references are used to retrieve rules in rules table  124  when enforcing policies at firewalls  110 . The structure of index table  126  and enforcement of policies will be described in more detail below. 
     Rules Distribution 
     Management platform  118  may distribute a copy of firewall rules for a group of workloads  106  running on hypervisor  104  of a host  102 . In some embodiments, the copy of firewall rules is for all workloads  106  running on hypervisor  104 . However, management platform  118  may provide different groups of firewall rules for groups of workloads  106  that are running on hypervisor  104 . For example, a first group of workloads  106  on host  102  may have an associated first copy of firewall rules and a second group of workloads  106  on host  102  may have a second copy of firewall rules. 
     LCP  120  receives and processes the firewall rules for workloads  106  from management platform  118 . LCP  120  reviews the rules and can generate index tables that reference each rule that is associated with a specific workload  106 .  FIG. 2  depicts a simplified flowchart  200  of a method for processing firewall rules according to some embodiments. At  202 , LCP  120  receives rules and information on which workloads to apply to the rules. LCP  120  may receive only one copy of the all the rules. At  204 , LCP  120  generates a rules table  124  that stores the rules. Rules table  124  may be a data structure, such as an index that refers to information for each of the firewall rules. 
       FIG. 3A  shows an example of a rules table according to some embodiments. A first column  302  may be an index and a second column  304  may store the information for the rule. In this example, the indices include #1, #2, . . . , #5 and there are five rules R1, R2, . . . , R5. The information for the rules may be stored in each entry in rules table  124  for each rule. For example, information for rule R1 is stored for index #1; the information for rule R2 is stored for index #2, etc. Although only one column for the rules is shown at  304 , the information for the rules may be stored in different formats. For example, each rule may list any combination of information that can be used to apply the rule to a packet, such as a 5-tuple of a source Internet protocol (IP) address, a destination IP address, protocol used, a layer 4 (L4) source port, and a layer 4 destination port. The 5-tuple may be stored in different columns, such as the source address is stored in a first column, the destination address is stored in a second column, etc. The information for the rules may also include an action to perform if the rule applies to a packet, such as “allow” or “block”. The allow action allows the packet to be sent or received by workload  106  and the block action does not send the packet from workload  106  or send the packet to workload  106 . Other actions may also be appreciated. 
     Referring back to  FIG. 2 , at  206 , LCP  120  selects a rule in the set of firewall rules. For example, the first rule R1 may be selected. Then, at  208 , LCP  120  determines workloads that are applied to that firewall rule. In some embodiments, each rule may include a statement, such as an “apply to” statement that lists the workloads  106  in which the rules should be applied. Each workload  106  may be identified by a VNIC identifier and LCP  120  determines the VNIC identifier for each workload  106  in which the rule applies. Although VNIC identifiers are discussed, other identifying information for a workload may be used. For example, the rules may be applied per datacenter, per a cluster of hosts, per a grouping of workloads, per a workload identifier, etc. Then, at  210 , LCP  120  adds a reference to each respective index table for the workloads for the rule. 
     At  212 , LCP  120  determines if another rule is found in the set of rules. If so, the process reiterates to  206  where another firewall rule is selected. The process continues to determine workloads associated with the new rule. LCP  120  then adds a reference to the rule to the respective index tables for the workloads. Once finished, each index table  126  may include a set of references that reference a set of rules in rules table  124 . Accordingly, when there are no more rules to analyze, at  214 , LCP  120  sends rules table  124  and index tables  126 - 1  to  126 -N to firewall manager  122 . 
       FIGS. 3B to 3D  depict examples of index tables  126 - 1  to  126 -N according to some embodiments. Rows of index tables  126 - 1  to  126 -N may list references to the rules. For example, in  FIG. 3B , for a workload  106 - 1 , index table  126  stores references to rules R1, R2, and R3. Referring to rules table  124  in  FIG. 3A , the indices for rules R1, R2, and R3 are #1, #2, and #3, respectively, and the indices may be used to retrieve the information for rules R1, R2, and R3 from rules table  124 . In  FIG. 3C , index table  126  lists references to rules R1, R3, and R5 for workload  106 - 2 . The indices in index table  126  are #1, #3, and #5, and correspond to respective indices in rules table  124 . Finally, in  FIG. 3D , index table  126 -N lists the rules for workload  106 -N. These rules are R1, R2, and R4 and refer to the indices of #1, #2, and #4 in rules table  124 . The references may be a pointer or other information that points to an entry in rules table  124 . The reference for a rule includes less information than the information for the rule itself. 
     Distributed Firewall 
     Firewall manager  122  may be running in the kernel space of hypervisor  104 . Once receiving rules table  124  from LCP  120 , firewall manager  122  stores a copy of rules table  124  in the memory of hypervisor  104 . In some embodiments, firewall manager  122  stores a single copy of rules table  124  in hypervisor  104  for the group of workloads  106 . 
     Firewall manager  122  then stores a copy of each respective index table  126  in a respective firewall  110  for each respective workload  106 . Each index table  126 - 1  to  126 -N may identify a specific workload  106 - 1  to  106 -N. For example, each index table  126  may reference a VNIC identifier for a respective workload  106 . Firewall manager  122  uses the VNIC identifier for an index table  126  to store the index table for that firewall  110 . Each firewall  110  then has an associated index table  126 . For example, firewall  110 - 1  includes an index table  126 - 1 , firewall  110 - 2  includes an index table  126 - 2 , and so on. In some examples, logic for firewall  110  may be instantiated between VNIC  116  and a port of virtual switch  112 . The rules are stored with the instantiation of firewall  110  between VNIC  116  and the port of virtual switch  112 . 
     Once index tables  126  and rules table  124  have been stored, firewalls  110  may process packets for workloads  106 .  FIG. 4  depicts a simplified flowchart  400  of a method for processing packets using firewall  110  according to some embodiments. At  402 , firewall  110  intercepts a packet that is being sent from workload  106  or is being sent to workload  106 , such as the packet is intercepted between VNIC  116  and virtual switch  112 . At  404 , firewall  110  extracts one or more attributes for the packet. In some examples, the attributes may be associated with characteristics of workload  106 , such as the 5-tuple described above; however, other combinations of attributes may be used. The attributes may be from different layers, such as attributes from layer 2 to layer 4. 
     At  406 , firewall  110  uses the references for the rules in index table  126  to access to the rules from rules table  124  and compares the attributes to the applicable rules in index table  126  to determine a rule that applies to the packet. For example, for workload  106 - 1 , firewall  110  retrieves references #1, #2, and #3 to rules R1, R2, and R3. Firewall  110  uses the references to access rules R1, R2, and R3 in rules table  124 . For example, information for rules R1, R2, and R3 are accessed at indices #1, #2, and #3 in rules table  124 . 
     Firewall  110  may access rules from rules table  124  in different ways. In some examples, firewall  110  communicates with firewall manager  122  by sending the reference to firewall manager  122 , which retrieves the rule and sends information for the rule to firewall  110 . In other examples, firewall  110  uses the reference to retrieve the applicable rule from rules table  124  without communicating with firewall manager  122 . 
     Firewall  110  may use different methods to perform the comparison. In some examples, firewall  110  enforces the rules from a top to bottom ordering. For each packet, firewall  110  checks the top rule listed in index table  126  before moving down to the subsequent rules listed in index table  126 . The first rule listed in index table  126  that matches the attributes is enforced using this policy. The last rule that is listed at the bottom of index table  126  may be a default rule that is enforced on the packet if no other rule has attributes that match the attributes of the packet. The default rule may not specify any particular attributes so that the default rule can match all packets. Although this top to bottom ordering policy is described, other methods may be used. For example, firewall  110  may determine all the rules that match the attributes and then select the one of the rules based on a ranking system. 
     Using the above process, firewall  110  may start with a first rule R1 listed in index table  126 , access rule R1 in rules table  124  using the reference #1, and then compare the attributes of the packet to the attributes listed for rule R1. In some embodiments, firewall  110  may access a source and destination from columns in rules table  124 , and compare the source and destination of the packet to the source and destination of the rule. If the attributes listed for rule R1 do not match the attributes of the packet, then firewall  110  proceeds to determine if attributes for rule R2 match the attributes of the packet. If the attributes for rule R2 do not match the attributes of the packet, then rule R3 is enforced as the default rule. 
     At  408 , once firewall  110  determines the applicable rule for the packets, firewall  110  determines an action for the rule. For example, the rule may list an action to perform, such as an action of allow the packet or block the packet. Then, at  410 , firewall  110  performs the action on the packet, which could route the packet to workload  106  or to virtual switch  112  if the packet is allowed, or just block the packet from being sent from or to workload  106 . 
     To improve the speed of filtering packets, firewall  110  may use a connection table together with the firewall rules. A connection table may store network connections in a fast lookup data structure such like hash table. Each network connection may be a unique identifier, such as a  5 -tuple, based on packet attributes. If the first packet of a connection is allowed by the firewall rules, firewall  110  inserts an instance of the connection into the connection table. The following packets in the same connection may be allowed as well. Firewall  110  may look up packets in the connection table before attempting to match the firewall rules. When a packet does not match any existing connections in the connection table, firewall  110  then compares the packet to the firewall rules in index table  126 . 
     Accordingly, hypervisor  104  uses less memory to store the rules. For example, hypervisor  104  may only store one copy of firewall rules R1 to R5, which uses memory to store five rules. However, workloads  106 - 1  to  106 -N may each have three applicable rules that are used totaling nine rules. If an individual copy of each rule is stored for workloads  106 - 1  to  106 -N, memory is used to store nine rules, which uses more memory than storing five rules. Thus, some embodiments eliminate the storage requirement for four rules in this example. For example, rule R1 does not need to be stored three times for workload  106 - 1 ,  106 - 2 , and  106 -N. Similarly, multiple copies of rule R2 do not need to be stored for workload  106 - 1 ,  106 -N, and multiple copies of rule R3 do not need to be stored for workloads  106 - 1  and  106 - 2 . The storage of individual copies of rules for each workload  106  is replaced by index tables and the storage of index tables  126  use significantly less space than the storage for individual sets of the rules for each workload  106  because storing the indices to rules uses less storage than the content of the rules themselves. 
     At some points, management platform  118  may update the firewall rules. LCP  120  receives a new copy of all the firewall rules for a group of workloads  106  that are running on hypervisor  104 . Then, LCP  120  recomputes index tables  126 - 1  to  126 -N for each workload  106 - 1  to  106 -N. Additionally, LCP  120  computes a new rules table  124 . LCP  120  then sends the new index tables  126  and new rules table  124  to firewall manager  122 . While LCP  120  generated the new index tables  126  and new rules table  124 , firewall manager  122  still uses existing index tables  126 - 1  to  126 -N and the existing rules table  124 . LCP  120  creates a new set of index tables  126  and rule table  124  to allow the distributed firewall to operate while the update is taking place. When the new index tables  126  and new rule table  124  are ready, firewall manager  122  can switch from using the previous index tables to new index tables and from the previous rules table to the new rules table. 
     Many variations, modifications, additions, and improvements are possible, regardless the degree of virtualization. The virtualization software can therefore include components of a host, console, or guest operating system that performs virtualization functions. Plural instances may be provided for components, operations or structures described herein as a single instance. Finally, boundaries between various components, operations and data stores are somewhat arbitrary, and particular operations are illustrated in the context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within the scope of the disclosure(s). In general, structures and functionality presented as separate components in exemplary configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. 
     Some embodiments described herein can employ various computer-implemented operations involving data stored in computer systems. For example, these operations can require physical manipulation of physical quantities—usually, though not necessarily, these quantities take the form of electrical or magnetic signals, where they (or representations of them) are capable of being stored, transferred, combined, compared, or otherwise manipulated. Such manipulations are often referred to in terms such as producing, identifying, determining, comparing, etc. Any operations described herein that form part of one or more embodiments can be useful machine operations. 
     Further, one or more embodiments can relate to a device or an apparatus for performing the foregoing operations. The apparatus can be specially constructed for specific required purposes, or it can be a general purpose computer system selectively activated or configured by program code stored in the computer system. In particular, various general purpose machines may be used with computer programs written in accordance with the teachings herein, or it may be more convenient to construct a more specialized apparatus to perform the required operations. The various embodiments described herein can be practiced with other computer system configurations including handheld devices, microprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like. 
     Yet further, one or more embodiments can be implemented as one or more computer programs or as one or more computer program modules embodied in one or more non-transitory computer readable storage media. The term non-transitory computer readable storage medium refers to any data storage device that can store data which can thereafter be input to a computer system. The non-transitory computer readable media may be based on any existing or subsequently developed technology for embodying computer programs in a manner that enables them to be read by a computer system. Examples of non-transitory computer readable media include a hard drive, network attached storage (NAS), read-only memory, random-access memory, flash-based nonvolatile memory (e.g., a flash memory card or a solid state disk), a CD (Compact Disc) (e.g., CD-ROM, CD-R, CD-RW, etc.), a DVD (Digital Versatile Disc), a magnetic tape, and other optical and non-optical data storage devices. The non-transitory computer readable media can also be distributed over a network coupled computer system so that the computer readable code is stored and executed in a distributed fashion. 
     These and other variations, modifications, additions, and improvements may fall within the scope of the appended claims(s). As used in the description herein and throughout the claims that follow, “a”, “an”, and “the” includes plural references unless the context clearly dictates otherwise. Also, as used in the description herein and throughout the claims that follow, the meaning of “in” includes “in” and “on” unless the context clearly dictates otherwise. 
     The above description illustrates various embodiments of the present disclosure along with examples of how aspects of the present disclosure may be implemented. The above examples and embodiments should not be deemed to be the only embodiments, and are presented to illustrate the flexibility and advantages of the present disclosure as defined by the following claims. Based on the above disclosure and the following claims, other arrangements, embodiments, implementations and equivalents may be employed without departing from the scope of the disclosure as defined by the claims.