JP2018527813A - Realization of cloud platform security - Google Patents

Abstract

The present invention provides a method and apparatus for realizing cloud platform security. In the present invention, an Openflow bridge that replaces the MAC bridge is constructed in the cloud server in the cloud platform, and the Openflow bridge realizes the security of the cloud platform by the Openflow security table. [Selection] Figure 3A

Description

  Security has always been an essential characteristic of each cloud platform. Both the current open source cloud platform and non-open source cloud platform realize the security of the cloud platform by dynamically learning Internet protocol (IP) table and layer 2 media access control (MAC) forwarding table To do.

  An open source cloud platform Openstack will be described as an example, but the principle of a non-open source cloud platform is similar. FIG. 1 shows a configuration diagram of any one cloud server in Openstack of an open source cloud platform. A primary bridge (a qbr bridge, also called a MAC bridge) of a Linux (registered trademark) kernel, for example, the MAC bridge_1, the MAC bridge_2, and the MAC bridge_3 illustrated in FIG. 1 includes a dynamically learned IP table and a layer 2 MAC forwarding table. To realize Openstack security for open source cloud platform. Taking packet transmission from the virtual machine (VM: Virtual Machine) 1 to VM 2 shown in FIG. 1 as an example, the VM 1 transmits a packet via the local port eth0, and the MAC bridge is the virtual network card (Veth: Virtual Ethernet) of the VM1. (Registered trademark)) receives a packet from VM1 at port Veth1 of the MAC bridge, performs filtering and identification of the packet by the IP table learned dynamically before that, and performs filtering after filtering by the dynamically learned Layer 2 MAC forwarding table Continue to forward packets.

FIG. 1 shows a configuration diagram of any one cloud server in Openstack of an open source cloud platform. FIG. 2 is a configuration diagram of any one cloud server in the cloud platform provided in the example of the present invention. FIG. 3A is a flowchart of a method for realizing security of a cloud platform using an open flow table provided in the example of the present invention. FIG. 3B is a flowchart of a method for forwarding a first packet based on a forwarding operation in a searched Openflow security table by a source Openflow bridge provided in an example of the present invention. FIG. 4 is a schematic diagram of a configuration of application network construction provided in an example of the present invention. FIG. 5 is a schematic diagram of the configuration of application network construction provided in another example of the present invention. FIG. 6 is a configuration diagram of an apparatus that realizes the security of the cloud platform by the Openflow table provided in the example of the present invention. FIG. 7 is a hardware configuration diagram of an apparatus that realizes the security of the cloud platform by the Openflow table provided in the example of the present invention.

  Currently, the MAC bridge on the cloud server in the cloud platform realizes the Openstack security of the open source cloud platform by the IP table and the layer 2 MAC forwarding table. However, the IP table and the layer 2 MAC forwarding table have poor controllability and are far inferior to the Openflow table. Further, all the entries in other bridges on the cloud server in the current cloud platform, for example, the internal bridge (BR-Int) and the external bridge (BR-Ext), are all in the Openflow table. Therefore, in the same cloud server, the IP table and the layer 2 MAC forwarding table in the MAC bridge and the Openflow table in other bridges are not unified.

  The present invention will be described in detail below with reference to the accompanying drawings and specific examples so that the objects, technical solutions, and merits of the present invention become clearer.

  In the present invention, in order to realize the security of the cloud platform by the Openflow table, an Openflow bridge is constructed on the cloud server in the cloud platform, and the security of the cloud platform is improved by the Openflow bridge instead of the MAC bridge described in the background art section. Realize. FIG. 2 is a configuration diagram of any one cloud server in the cloud platform provided by the present invention. As shown in FIG. 2, the Openflow bridge is connected between the VM and the BR-Int at the same position as the MAC bridge described in the background art section. However, the MAC bridge realizes the security of the cloud platform by the dynamically learned IP table and the layer 2 MAC forwarding table, whereas in the present invention, the Openflow bridge uses the Openflow security table arranged in advance to provide the security of the cloud platform. To realize.

  In the present invention, the Openflow security table includes a plurality of Openflow security entries, and each of the Openflow security entries includes two parts: a matching condition and a transfer operation.

  As an example of the present invention, the matching condition here may include a packet reception port and a packet attribute parameter mounted on the packet. In one example, the packet attribute parameter mounted on the packet may be at least one of a packet 5 tuple and a packet 7 tuple. Here, the packet 5 tuple is the destination IP address, source IP address, destination port number, source port number, and protocol type, and the packet 7 tuple is the destination IP address, source IP address, destination MAC address, source MAC address. , Destination port number, source port number, and protocol type.

  As an example of the present invention, the transfer operation may be a transfer operation that is performed on a packet that matches an Openflow security entry. Details of the packet transfer by the transfer operation in the Openflow security entry will be described later.

  Based on the above description, the following describes in detail the procedure by which the Openflow bridge realizes the security of the cloud platform by using an Openflow security table arranged in advance.

  Refer to FIG. 3A. FIG. 3A is a flowchart of a method for realizing the security of the cloud platform using the Openflow table provided in the present invention. This flow is applied to the Openflow bridge as described above. As shown in FIG. 3A, this flow includes the following steps.

  In step 301, a packet is received.

  In this step, the packet may be a first packet from the local VM or a second packet destined for the local VM.

  However, the first packet and the second packet here are only for distinguishing between the packet from the VM and the packet addressed to the VM, and do not limit the present invention.

  In step 302, if the packet is a packet from the local VM or a packet destined for the local VM, the packet is placed in advance locally using the port that received the packet and the packet attribute parameter mounted in the packet as keywords The Openflow security entry whose matching condition is the keyword is searched from the openflow security table. When the search is performed, the packet is transferred based on the transfer operation in the searched Openflow security entry. When the search is not performed, the packet is discarded.

  For convenience of explanation, the Openflow bridge that receives the first packet from the local VM is referred to as a source Openflow bridge, and the Openflow bridge that receives the second packet addressed to the local VM is referred to as a destination Openflow bridge. In the following description, the Openflow bridge is divided into a source Openflow bridge and a destination Openflow bridge.

  The source Openflow bridge uses the first port that has received the first packet and the packet attribute parameter mounted on the first packet as the first keyword from the Openflow security table that is locally arranged in advance. The Openflow security entry whose matching condition is the first keyword is searched. When the source Openflow bridge is searched, the source Openflow bridge transfers the first packet based on the transfer operation in the searched Openflow security entry. When the source Openflow bridge is not searched, the source Openflow bridge discards the first packet.

  The destination Openflow bridge uses the second port that received the second packet and the packet attribute parameter mounted on the second packet as the second keyword from the Openflow security table that is locally arranged in advance. An Openflow security entry whose matching condition is the second keyword is searched. When the destination Openflow bridge is searched, the destination Openflow bridge transfers the second packet to the VM via the first port based on the transfer operation in the searched Openflow security entry. , Discard the second packet.

  As an example, forwarding a second packet based on a forwarding operation in the retrieved Openflow security entry is to forward the second packet to the VM via the first port of the Openflow bridge connected to the VM. It may include transmitting.

  So far, the flow shown in FIG. 3A is completed.

  As an example of the present invention, FIG. 3B is a flowchart of a method provided by the example of the present invention, in which the source Openflow bridge forwards the first packet based on the forwarding operation in the searched Openflow security table. As shown in FIG. 3B, forwarding the first packet based on the forwarding operation in the retrieved Openflow security entry by the source Openflow bridge includes the following steps.

  In step a1, the source Openflow bridge determines whether or not the first packet is the leading packet, and executes step a2 if the first packet is the leading packet, and the first packet is not the leading packet. In that case, step a3 is executed.

  Here, since the method for determining whether or not the first packet is the head packet is similar to the conventional method for determining the head packet, detailed description thereof is omitted.

  In step a2, the source Openflow bridge sends the first packet to the third port on the BR-Int that becomes a peer with the second port via the second port on the Openflow bridge. Forward. Then, the current flow ends.

  This step a2 is executed on the assumption that the first packet is the head packet.

  In the present invention, when the first packet is the first packet, the source Openflow bridge sends the second port on the BR-Int and the peer (Peer) via the second port on the Openflow bridge. The first packet is transmitted to the third port. Thus, the first packet arrives at the third port on BR-Int. When the BR-Int receives the first packet via the third port, it searches the local Openflow transfer table for an Openflow transfer entry that matches the first packet (the searched Openflow transfer entry is found). (Denoted as entry 1), and continues to transfer the first packet based on the transfer operation in the searched entry 1.

  When the destination device of the first packet is another VM on the same cloud server, the forwarding operation in the entry 1 searched by the BR-Int is performed via the fourth port on the BR-Int. In this operation, the first packet is transmitted to the fifth port that is peered with the fourth port on the Openflow bridge (that is, the destination Openflow bridge) connected to the destination device. Based on this, the BR-Int transmits the first packet to the fifth port peering with the fourth port on the destination Openflow bridge via the fourth port on the BR-Int. When the destination Openflow bridge receives the first packet via the fifth port, the first packet is addressed to the local VM, and therefore the first packet is received as described in step 303. Based on the fifth port and the packet attribute parameter mounted on the first packet, an Openflow security entry that matches the first packet is searched from an Openflow security table that is locally arranged in advance. Then, when the destination Openflow bridge is searched (the searched Openflow security entry is described as entry 2), the destination Openflow bridge passes through the output port connected to the destination device based on the transfer operation in the searched entry 2. The first packet is transmitted to the destination device, and finally the first packet arrives at the destination device. If no search is made, the first packet is discarded.

  If the destination device of the first packet is a physical host on the network or another VM on another cloud server, the forwarding operation in entry 1 retrieved by BR-Int is the sixth on the BR-Int. In this operation, the first packet is transmitted to the seventh port that is a peer with the sixth port on the BR-Ext via the port. Based on this, the BR-Int transmits the first packet via the sixth port on the BR-Int to the seventh port peering with the sixth port on the BR-Ext. When the BR-Ext receives the first packet, it searches the local Openflow transfer table for an Openflow transfer entry that matches the first packet (describes the searched Openflow transfer entry as entry 3). The transfer of the first packet is continued based on the transfer operation in the entered entry 3. Here, in the transfer operation in the searched entry 3, the first packet is VXLAN-encapsulated, and is VXLAN-encapsulated via a physical port on BR-Ext (routing output port connected to the destination device). The operation may be to transfer the first packet. Thus, the first packet finally arrives at the destination device.

  As described above, when the first packet is the first packet to the destination device and the destination device is another VM on the same cloud server, the first performed in the source Openflow bridge, BR-Int, and destination Openflow bridge Or the first packet is the first packet to the destination device, and the destination device is a physical host on the network or another VM on another cloud server, the source Openflow bridge, BR-Int In the present invention, a controller (for example, an SDN controller) on the cloud platform further includes an Openflow transfer entry (denoted as entry 4) for the first packet transfer. That) to dynamically generate, it may be stored to distribute the source Openflow bridge. For example, entry 4 may be stored in the Openflow transfer table of the source Openflow bridge.

  In the present invention, when the first packet is a head packet to the destination device and the destination device is another VM on the same cloud server, the entry 4 is based on the principle of non-overlapping. This entry is a combination of Openflow entries that match the first packet, which are searched when the packet passes through the source Openflow bridge, BR-Int, and destination Openflow bridge. For example, if the first packet is the first packet to the destination device and the destination device is another VM on the same cloud server, the first packet is the source Openflow bridge described above, Transferred via BR-Int and destination Openflow bridge. The matching condition of the entry 4 is the matching condition in the Openflow security entry that matches the first packet that is searched when the first packet passes through the source Openflow bridge, and the first packet passes through BR-Int. Matching conditions in the Openflow forwarding entry that matches the first packet, which are sometimes retrieved, and in the Openflow security entry that matches the first packet, which is retrieved when the first packet passes through the destination Openflow bridge BR-Int. It is a combination with a matching condition (however, it is necessary to ensure that the finally combined matching condition has no duplicate contents). In addition, the transfer operation of entry 4 includes the transfer operation in the Openflow security entry that matches the first packet, which is searched when the first packet passes through the source Openflow bridge, and the first packet passes through BR-Int. The forwarding operation in the Openflow forwarding entry that matches the first packet that is searched when the first packet is searched, and the forwarding operation in the Openflow security entry that matches the first packet that is searched when the first packet passes through the destination Openflow bridge (However, in the finally combined transfer operation, the intermediate step transfer operation may be omitted. That is, only the transfer operation in the entry 2 described above may be left).

  If the first packet is the first packet to the destination device and the destination device is a physical host on the network or another VM on another cloud server, entry 4 is based on the principle of non-overlapping. This is a combination of Openflow entries that match the first packet, searched when one packet passes through the source Openflow bridge, BR-Int, and BR-Ext. By way of example, if the first packet is the first packet to the destination device and the destination device is a physical host on the network or another VM on another network node, the first packet is Transfer is performed via the above-described source Openflow bridge, BR-Int, and BR-Ext. The matching condition of the entry 4 is the matching condition in the Openflow security entry that matches the first packet that is searched when the first packet passes through the source Openflow bridge, and the first packet passes through BR-Int. A combination of the matching condition in the Openflow transfer entry that matches the first packet and the matching condition in the Openflow transfer entry that matches the first packet when the first packet passes through BR-Ext, Yes (however, it is necessary to ensure that the finally combined matching conditions have no duplicate content). In addition, the transfer operation of entry 4 includes the transfer operation in the Openflow security entry that matches the first packet, which is searched when the first packet passes through the source Openflow bridge, and the first packet passes through BR-Int. The combination of the transfer operation in the Openflow transfer entry that matches the first packet and the transfer operation in the Openflow transfer entry that matches the first packet when the first packet passes through the BR-Ext. (However, in the finally combined transfer operation, intermediate step transfer operations may be omitted, but other non-transfer operations such as VXLAN encapsulation need not be omitted).

  As can be seen from entry 4 above, if the first packet is the first packet to the destination device, then the destination device is another VM on the same cloud server, or a physical host on the network or another Regardless of whether it is another VM on the cloud server, entry 4 will eventually contain an Openflow entry that matches the first packet that was retrieved when the first packet went through each bridge on the cloud server. It is a collection. As a result, for the non-first packet transmitted to the destination device thereafter, the Openflow transfer entry only needs to be searched once in the source Openflow bridge, and the Openflow entry is not searched in each other bridge in the cloud server. Since the packet can be transferred to the destination device, the packet transfer efficiency is increased. Details will become apparent with reference to step a3.

  In step a3, the source Openflow bridge searches for an Openflow transfer entry (that is, the entry 4) that matches the first packet from the local Openflow transfer table, and sets the first Openflow bridge based on the transfer operation in the searched Openflow transfer entry. 1 packet is transferred. Then, the current flow ends.

  This step a3 is executed on the assumption that the first packet is a non-first packet.

  As is clear from the entry 4 described above, the entry 4 is a collection of Openflow entries that match the first packet searched when the first packet to the destination device passes through each bridge in the cloud server. Based on this, if the first packet is a non-leading packet to the destination device, the Openflow forwarding entry matching the first packet, in which the source Openflow bridge is searched from the local Openflow forwarding table in step a3, is , Entry 4 above. The entry 4 is a collection of Openflow entries that match the first packet that is searched when the first packet to the destination device passes through each bridge in the cloud server. Based on this, transferring the first packet based on the transfer operation in the searched Openflow transfer entry in this step a3 directly transfers the first packet across each bridge in the cloud server. It becomes. In this way, when forwarding the first packet to the destination device, it is only necessary to search the Openflow forwarding table once in the source Openflow bridge, and it is necessary to search the Openflow entry in each of the other bridges in the cloud server. The packet transfer efficiency is high.

  An example will be described in which the packet p1 is a non-leading packet to a destination device (another VM in the same cloud server). When the source Openflow bridge receives the packet p1 and finds that the packet p1 is a non-first packet to the destination device, the source Openflow bridge searches the local Openflow transfer table for an Openflow transfer entry that matches the packet p1, and searches for it. The packet p1 is transferred based on the transfer operation in the opened Openflow transfer entry. Here, the Openflow transfer entry that matches the packet p1 is a collection of Openflow entries that match the first packet that are searched when the first packet to the destination device passes through the source Openflow bridge, the BR-Int, and the destination Openflow bridge. is there. As described above, the transfer of the packet p1 based on the transfer operation in the searched Openflow transfer entry finally causes the packet p1 to cross the source Openflow bridge, the BR-Int, the destination Openflow bridge, and to send the packet p1 to the destination on the destination Openflow bridge. It will be sent to the port connected to the device. Further, the packet p1 may be directly transferred via this port, and there is no need to further search and transfer the Openflow entry in the BR-Int and the destination Openflow bridge.

  In the present invention, in order to ensure the smooth execution of steps a1 to a3, each bridge in the same cloud server may be defined to be connected by a port whose port type is Patch. Specifically, to the second port on the source Openflow bridge, the third port on BR-Int that peers with the second port, the fourth port on BR-Int, the fourth port and peer The fifth port on the destination Openflow bridge, the sixth port on the BR-Int, and the seventh port on the BR-Ext that peers with the sixth port are of port type Patch. When the port type is Patch, the first packet is an Openflow type bridge (actually, a bridge having an Openflow entry. For example, an Openflow bridge, BR-Int, BR-Ext, etc.) connected by a Patch type port. ), The Openflow entries of all Openflow type bridges can be automatically combined, and finally one Openflow transfer entry (for example, when the first packet is the first packet in the above step a2) A generated entry 4) can be generated to guide traffic forwarding for subsequent non-leading packets.

  The step 302 has been described above.

  The method flow shown in FIG. 3A will be described below with two examples.

  FIG. 4 is a schematic diagram of application network construction in an example. The application network construction of FIG. 4 illustrates only a network of one server in the cloud platform. As shown in FIG. 4, VM_11 is connected to the virtual network card Veth_11 on the Openflow bridge_11 by the local port eth_11, and VM_12 is connected to the virtual network card Veth_12 of the Openflow bridge_12 by the local port eth_12. The VM_1n is connected to the virtual network card Veth_1n of the Openflow bridge_1n through the local port eth_1n. In FIG. 4, the Openflow bridge_11 is connected to the port Patch_Int_11 of the BR-Int by the port Patch_VM_11, and the Openflow bridge_12 is connected to the port Patch_Int_12 of the BR-Int by the port Patch_VM_12. _1n is connected to the port Patch_Int_1n of BR-Int by the port Patch_VM_1n. Among them, the port Patch_VM_11 on the Openflow bridge_11 and the port Patch_Int_11 on the BR-Int are peers with each other, the port type is Patch, the port Patch_VM_12 on the Openflow bridge_12 and the port Patch_Int_12 on the BR-Int are peers with each other The port type is Patch, and the analogy is thus made. The port Patch_VM_1n on the Openflow bridge_1n and the port Patch_Int_1n on the BR-Int are peers with each other, and the port type is Patch. In FIG. 4, BR-Int is connected to a port Patch_41 on BR-Ext by a port Patch_40, and the port types of Patch_40 and Patch_41 are Patch. In FIG. 4, VM_11 to VM_1n, Openflow bridge_11 to Openflow bridge_1n, BR-Int, and BR-Ext are located in the same cloud server.

  In this example, access from VM_11 to VM_12 will be described as an example as follows.

  The VM_11 transmits a packet for accessing the VM_12 via the eth_11. For convenience of explanation, the packet here is referred to as a packet 01.

  When the Openflow bridge_11 receives the packet 01 via the Veth_11 and finds that the packet 01 is the first packet received from the VM_11 to the VM_12 (that is, the first packet), the Veth_11 and the packet mounted on the packet 01 are detected. Using the attribute parameter as a keyword, an Openflow security entry whose matching condition is the keyword is searched from an Openflow security table that is locally arranged in advance.

  The Openflow bridge_11 directly discards the packet 01 when the Openflow security entry is not searched.

  When the Openflow security entry is searched (the searched Openflow security entry is referred to as entry 41), the Openflow bridge_11 sends the packet 01 via the port Patch_VM_11 of the Openflow bridge_11 based on the transfer operation in the entry 41. And continue sending.

  When the BR-Int receives the packet 01 via the Patch_Int_11, the BR-Int searches for an Openflow transfer entry that matches the packet 01 from the local Openflow transfer table (this opened Openflow transfer entry is described as an entry 42). Based on the transfer operation in the entry 42, the packet 01 is transferred through the port Patch_Int_12.

  When the Openflow bridge_12 receives the packet 01 via the Patch_VM_12 and finds that the packet 01 is a packet addressed to the VM_12, the Openflow bridge_12 is locally arranged in advance using the Patch_VM_12 and the packet attribute parameter mounted on the packet 01 as keywords. The Openflow security entry whose matching condition is this keyword is searched from the Openflow security table that has been set. Then, when the Openflow bridge_12 is searched (here, the searched Openflow security entry is described as the entry 43), the packet 01 is transmitted via the port Veth_12 of the Openflow bridge_12 based on the transfer operation in the entry 43. Send. Finally, the packet 01 transmitted from the VM_11 arrives at the VM_12, and access from the VM_11 to the VM_12 is realized.

  The SDN controller on the cloud platform transmits the entry 41 searched when the packet 01 passes through the Openflow bridge_11 during the transfer of the packet 01 performed by the Openflow bridge_11, BR-Int, and Openflow bridge_12, and the packet 01 is the BR -Openflow forwarding entry (denoted as entry 40) matching the packet 01 by collecting the entry 42 searched when passing through the Int and the entry 43 searched when the packet 01 passes through the Openflow bridge_12 Further, it is generated and distributed to the Openflow transfer table of the Openflow bridge_11. The matching condition in the entry 40 is a non-overlapping collection of matching conditions in the entries 41 to 43, and the transfer operation in the entry 40 is a non-overlapping collection of transfer operations in the entries 41 to 43. Here, a transfer operation of transferring via the port Veth_12 of the Openflow bridge_12 will be described as an example.

  Thereafter, when the VM_11 accesses the VM_12 again, the VM_11 transmits a packet for accessing the VM_12 via the eth_11. For convenience of explanation, the packet here is referred to as a packet 02.

  When the Openflow bridge_11 receives the packet 02 via the Veth_11 and finds that the packet 02 is not the first packet received from the VM_11 to the VM_12 (that is, a non-first packet), the Openflow bridge_11 detects from the local Openflow forwarding table. The Openflow transfer entry matching the packet 02 (that is, the entry 40 generated by the SDN controller) is searched.

  Based on the transfer operation in the searched entry 40, the Openflow bridge_11 transparently transfers the packet 02 to Veth_l2 of the Openflow bridge_12, and operates the Openflow bridge_12 to transfer the packet 02 via the Veth_12. Eventually, the packet 02 transmitted from the VM_11 arrives at the VM_12, and re-access from the VM_11 to the VM_12 is realized.

  FIG. 5 is a schematic diagram of application network construction in another example. The application network construction of FIG. 5 illustrates only a network of one server in the cloud platform. As shown in FIG. 5, VM_21 is connected to the virtual network card Veth_21 of the Openflow bridge_21 by the local port eth_21, and VM_22 is connected to the virtual network card Veth_22 of the Openflow bridge_22 by the local port eth_22. The VM_2n is connected to the virtual network card Veth_2n of the Openflow bridge_2n through the local port eth_2n. In FIG. 5, the Openflow bridge_21 is connected to the port Patch_Int_21 of the BR-Int by the port Patch_VM_21, and the Openflow bridge_22 is connected to the port Patch_Int_22 of the BR-Int by the port Patch_VM_22. _2n is connected to the port Patch_Int_2n of BR-Int by the port Patch_VM_2n. Among them, the port Patch_VM_21 on the Openflow bridge_21 and the port Patch_Int_21 on the BR-Int are peers with each other, the port type is Patch, the port Patch_VM_22 on the Openflow bridge_22 and the port Patch_Int_22 on the BR-Int are peers with each other The port type is Patch. By analogy in this way, the port Patch_VM_2n on the Openflow bridge_2n and the port Patch_Int_2n on the BR-Int are peers with each other, and the port type is Patch. In FIG. 5, BR-Int is connected to a port Patch_51 on BR-Ext by a port Patch_50, and the port types of Patch_50 and Patch_51 are Patch. VM_21 to VM_2n, Openflow bridge_21 to Openflow bridge_2n, BR-Int, and BR-Ext in FIG. 5 are located on the same server.

  In this example, access from the VM_21 to the physical host PM_21 on the network will be described as an example as follows.

  VM_21 transmits a packet for accessing PM_21 via eth_21. For convenience of explanation, the packet here is referred to as a packet 21.

  When the Openflow bridge_21 receives the packet 21 via the Veth_21 and finds that the packet 21 is a packet (that is, the first packet) from the VM_21 to the PM_21 received by the Openflow bridge_21 for the first time, the packet 21 Using the installed packet attribute parameter as a keyword, an Openflow security entry whose matching condition is this keyword is searched from an Openflow security table previously arranged locally.

  The Openflow bridge_21 directly discards the packet 21 when the Openflow security entry is not retrieved.

  When an Openflow security entry is searched (this searched Openflow security entry is described as an entry 51), the Openflow bridge_21 sends the packet 21 via the port Patch_VM_21 of the Openflow bridge_21 based on the transfer operation in the entry 51. And continue sending.

  When the BR-Int receives the packet 21 via the Patch_Int_21, the BR-Int searches for an Openflow transfer entry that matches the packet 21 from the local Openflow transfer table (this searched Openflow transfer entry is referred to as an entry 52). Based on the transfer operation in the entry 52, the packet 21 is transferred through the port Patch_50.

  The BR-Ext receives the packet 21 via the Patch_51, and searches the Openflow transfer entry that matches the packet 21 from the local Openflow transfer table (here, this searched Openflow security entry is described as the entry 53). To do). Also, the BR-Ext encapsulates the packet 21 based on the encapsulation operation in the transfer operation of the searched entry 53, and passes the physical port Port_21 based on the transfer operation in the transfer operation of the searched entry 53. Forward. Finally, the packet 21 transmitted from VM_21 arrives at PM_21, and access from VM_21 to PM_21 is realized.

  The SDN controller on the cloud platform includes an entry 51 searched when the packet 21 passes through the Openflow bridge_21 during transfer of the packet 21 performed by the Openflow bridge_21, BR-Int, and BR-Ext, and the packet 21 is stored in the BR. -The entry 52 searched when passing through Int and the entry 53 searched when the packet 21 passes through BR-Ext are collected together, and an Openflow transfer entry (denoted as entry 50) matching the packet 21 is obtained. Furthermore, it produces | generates and delivers to the Openflow transfer table of Openflow bridge_21. The matching condition in the entry 50 is a non-overlapping collection of matching conditions in the entries 51 to 53. The transfer operation in the entry 50 is a non-overlapping collection of transfer operations in the entries 51 to 53. Here, a transfer operation in which VXLAN encapsulation is performed and transferred via the physical port Port_21 will be described as an example.

  Thereafter, when the VM_21 accesses the PM_21 again, the VM_21 transmits a packet for accessing the PM_21 via the eth_21. For convenience of explanation, the packet here is referred to as a packet 22.

  When the Openflow bridge_21 receives the packet 22 via the Veth_21 and finds that the packet 22 is not a packet from the VM_21 to the PM_22 received by the Openflow bridge_21 for the first time (that is, a non-first packet), the local Openflow transfer is performed. An Openflow transfer entry matching the packet 22 is searched from the table (that is, the entry 50 generated by the SDN controller).

  Based on the transfer operation in the searched entry 50, the Openflow bridge_21 encapsulates the packet 22 in VXLAN and transparently transfers the packet 22 to the BR-Ext physical port Port_21. The VXLAN encapsulated packet 22 is transmitted through the physical port Port_21. Operate BR-Ext to transfer. Finally, the packet 22 transmitted again from the VM_21 arrives at the VM_21, and the re-access from the VM_21 to the PM_21 is realized.

  The above is a description of the method provided by the present invention. The apparatus provided by the present invention will be described below.

  Please refer to FIG. FIG. 6 is a configuration diagram of an apparatus that realizes the security of the cloud platform by the Openflow table provided in the example of the present invention. This device is a device used in an Openflow bridge that is built in a cloud server in the cloud platform and replaces the MAC bridge, and the Openflow bridge is connected between the VM on the cloud server and the BR-Int. This apparatus includes an Openflow entry storage unit 601, an output traffic control unit 602, and an input traffic control unit 603.

  Among them, the Openflow entry storage unit 601 stores an Openflow security table arranged in advance.

  The output traffic control means 602 receives the first packet from the local VM, and uses the first port that has received the first packet and the packet attribute parameter mounted on the first packet as the first keyword. The Openflow security table stored in the Openflow entry storage means is searched for an Openflow security entry whose matching condition is the first keyword, and when the search is found, based on the transfer operation in the searched Openflow security entry. The first packet is transferred, and if it is not searched, the first packet is discarded.

  The input traffic control means 603 receives the second packet addressed to the VM, uses the second port that has received the second packet, and the packet attribute parameter mounted on the second packet as the second keyword. In the Openflow security table stored in the Openflow entry storage means, the Openflow security entry whose matching condition is the second keyword is searched, and when the search is performed, the transfer operation in the searched Openflow security entry is performed. Based on this, the second packet is transferred, and if it is not searched, the second packet is discarded.

  The Openflow entry storage unit 601 preferably further stores an Openflow transfer table.

  Based on this, the output traffic control means 602 transfers the first packet based on the transfer operation in the searched Openflow security entry. When the first packet is the first packet, When the first packet is transmitted to the third port that is peered with the second port on the BR-Int via the second port, and the first packet is not the first packet The Openflow transfer table stored in the Openflow entry storage unit 601 is searched for an Openflow transfer entry that matches the first packet, and the first packet is transferred based on the transfer operation in the searched Openflow transfer entry. Including doing.

  Here, when the first packet is a head packet, the Openflow entry storage unit 601 further receives an Openflow transfer entry that matches the first packet generated and distributed by the controller in the cloud platform, The received Openflow transfer entry is stored in the local Openflow transfer table.

  Here, when the first packet is the first packet from the VM to the destination device and the destination device is another VM on the same cloud server, the Openflow forwarding entry that matches the first packet is Openflow security entry that matches the first packet that is searched when the first packet passes through the Openflow bridge and the first packet that is searched when the first packet passes through BR-Int This is a combination of an Openflow forwarding entry to be matched with an Openflow security entry that matches the first packet that is searched when the first packet passes through the destination Openflow bridge connected to the destination device. If the first packet is the first packet to the destination device and the destination device is a physical host on the network or another VM on another cloud server, the Openflow forwarding entry that matches the first packet is Openflow security entry that matches the first packet that is searched when the first packet passes through the Openflow bridge and the first packet that is searched when the first packet passes through BR-Int This is a combination of an Openflow transfer entry to be matched with an Openflow transfer entry that matches the first packet that is searched when the first packet passes through the external bridge BR-Ext.

  In one example, the Openflow bridge, BR-Int, and BR-Ext on the cloud server are connected by a port whose port type is Patch.

  In one example, the input traffic control means 603 transfers the second packet based on the transfer operation in the searched Openflow security entry via the first port of the Openflow bridge connected to the VM. , Sending a second packet to the VM.

  The above is a description of the apparatus shown in FIG.

  The present invention further provides a hardware configuration diagram of the apparatus shown in FIG. Please refer to FIG. FIG. 7 is a hardware configuration diagram of an apparatus that realizes cloud platform security by the Openflow table shown in FIG. 6 provided in the present invention. As shown in FIG. 7, the hardware configuration diagram includes a memory 710, a processor 720 communicatively connected to the memory 710, and an interface 730. Here, the memory 710 may be a non-volatile storage medium and stores computer-executable commands executed by the processor 720. This computer-executable command can realize the operation of the method for realizing the security of the cloud platform shown in any one of FIGS. The computer-executable command can also realize the operation of the device that realizes the security of the cloud platform by the Openflow table shown in FIG.

  Alternatively, the memory 710 may be understood to store the Openflow entry storage unit 601, the output traffic control unit 602, and the input traffic control unit 603 in FIG. In response to this, the processor 720 executes the control program for operating the Openflow entry storage unit 601, thereby controlling the Openflow entry storage unit 601 in the memory 710 to execute the operation as described above, and the output traffic control unit. By executing the control program for operating 602, the output traffic control means 602 in the memory 710 is controlled to execute the operation as described above, and the control program for operating the input traffic control means 603 is executed. The input traffic control means 603 at 710 is controlled to execute the above operation.

  The present invention provides a method and apparatus for realizing security of a cloud platform. In the present invention, an Openflow bridge that replaces the MAC bridge is constructed in the cloud server in the cloud platform, and the Openflow bridge realizes the security of the cloud platform by the Openflow security table. Thus, the purpose of realizing the security of the cloud platform by the Openflow table is achieved, and the control performance of the cloud platform security is improved. In the present invention, the Openflow bridge realizes the security of the cloud platform by the Openflow type flow table, and adopts other bridges on the cloud server such as BR-Int and BR-Ext (also the Openflow type flow table is used similarly). Network management and management using the same flow table, the network arrangement and management can be simplified.

  The above are only preferred embodiments of the present invention and do not limit the present invention. Any change, equivalent replacement, improvement and the like within the scope not departing from the spirit and spirit of the present invention are included in the scope of the right of the present invention.

Claims (10)

A method for realizing security of a cloud platform between a virtual machine (VM) and an internal bridge (BR-Int) on the cloud server, which is constructed in a cloud server in the cloud platform and substitutes for a MAC bridge In the method used for the Openflow bridge located in
Receive the packet,
When the packet is a packet from a local VM or a packet destined for a local VM, Openflow security that is locally arranged in advance using the port that received the packet and the packet attribute parameter mounted on the packet as keywords. When the Openflow security entry whose matching condition is the keyword is searched from the table, and the packet is searched, the packet is transferred based on the transfer operation in the searched Openflow security entry. And discarding the packet. When the packet is a packet from a local VM and the port that received the packet is the first port, forwarding the packet based on the forwarding operation in the retrieved Openflow security entry includes:
If the packet is a leading packet, send the packet to a third port on the BR-Int that is a peer to the second port via the second port on the Openflow bridge;
When the packet is not the first packet, the method includes searching for an Openflow transfer entry matching the packet from a local Openflow transfer table, and transferring the packet based on a transfer operation in the searched Openflow transfer entry. Item 2. The method according to Item 1. If the packet is the first packet,
Receiving an Openflow forwarding entry generated and distributed by a controller in a cloud platform that matches the packet, and storing the received Openflow forwarding entry in a local Openflow forwarding table;
If the packet is the first packet from the VM to the destination device and the destination device is another VM on the same cloud server, the Openflow forwarding entry that matches the packet is sent via the Openflow bridge. The Openflow security entry that matches the packet that is searched when the packet is searched, the Openflow forwarding entry that matches the packet that is searched when the packet passes through BR-Int, and the packet is connected to the destination device. A combination with an Openflow security entry that matches the packet retrieved when going through the destination Openflow bridge;
If the packet is the first packet to the destination device and the destination device is a physical host on the network or another VM on another cloud server, the Openflow forwarding entry that matches the packet is the packet that the Openflow An Openflow security entry that matches the packet searched when passing through the bridge, an Openflow forwarding entry that matches the packet searched when the packet passes through BR-Int, and the packet is an external bridge (BR The method according to claim 2, wherein the method is a combination with an Openflow forwarding entry that matches the packet, which is searched when going through -Ext).   4. The method according to claim 3, wherein the Openflow bridge, BR-Int, and BR-Ext on the cloud server are connected by a port whose port type is Patch. If the packet is a packet destined for a local VM and the port that received the packet is a second port, forwarding the packet based on the forwarding operation in the retrieved Openflow security entry includes:
The method according to claim 1, comprising transmitting the packet to the VM via a first port of the Openflow bridge connected to the VM. A device for realizing security of a cloud platform, which is constructed in a cloud server in the cloud platform and substitutes for a MAC bridge, between a virtual machine (VM) on the cloud server and an internal bridge (BR-Int) In the device used for the Openflow bridge located in
Including processor and memory,
The memory stores computer executable commands executable by the processor,
The computer executable command is:
Receiving a packet;
When the packet is a packet from the local VM or a packet destined for the local VM, an Openflow security table stored in advance locally using the port that received the packet and the packet attribute parameter mounted on the packet as keywords. When the Openflow security entry whose matching condition is the keyword is searched from among the packets, the packet is transferred based on the transfer operation in the searched Openflow security entry, and when the search is not performed, An operation of discarding the packet;
That causes the processor to execute. If the packet is a packet from a local VM and the port that received the packet is the first port, the computer executable command is:
If the packet is the first packet, the first packet is transmitted to the third port on the BR-Int that is a peer with the second port via the second port on the Openflow bridge; If the packet is not the first packet, the Openflow transfer table stored in the Openflow entry storage means is searched for an Openflow transfer entry that matches the packet, and based on the transfer operation in the searched Openflow transfer entry. The apparatus of claim 6, causing the processor to perform an operation of forwarding a packet. If the packet is the first packet, the computer executable command further receives an Openflow transfer entry that is generated and distributed by the controller in the cloud platform and matches the packet, and the received Openflow transfer entry is transferred to the local Openflow. Causing the processor to perform the operations stored in the table;
If the packet is the first packet from the VM to the destination device and the destination device is another VM on the same cloud server, the Openflow forwarding entry that matches the packet is sent via the Openflow bridge. The Openflow security entry that matches the packet that is searched when the packet is searched, the Openflow forwarding entry that matches the packet that is searched when the packet passes through BR-Int, and the packet is connected to the destination device. A combination with an Openflow security entry that matches the packet retrieved when going through the destination Openflow bridge;
If the packet is the first packet to the destination device and the destination device is a physical host on the network or another VM on another cloud server, the Openflow forwarding entry that matches the packet is the packet that the Openflow An Openflow security entry that matches the packet searched when passing through the bridge, an Openflow forwarding entry that matches the packet searched when the packet passes through BR-Int, and the packet is an external bridge (BR The apparatus according to claim 7, wherein the apparatus is a combination with an Openflow transfer entry that matches the packet, which is searched when passing through (Ext).   The apparatus according to claim 8, wherein the Openflow bridge, BR-Int, and BR-Ext on the cloud server are connected by a port whose port type is Patch. If the packet is a packet addressed to the VM and the port that received the packet is a second port, the computer executable command is:
The apparatus according to claim 6, wherein the processor performs an operation of transmitting the packet to the VM via a first port connected to the VM of the Openflow bridge.