本发明属于云计算的可信云领域，涉及一种基于云平台的多租户网络拓扑重构方法。
背景技术：
：：近年来，云计算成为信息
技术领域：
：讨论的热点，越来越多的企业和个人用户选择把业务系统部署到云平台上。由于云计算共享底层资源的特性，多租户隔离问题成为各大公有云平台需要解决的关键问题之一。网络虚拟化技术作为主流公有云平台的网络实现基础，为云平台的多租户网络隔离提供保证。然而，在多租户的云环境下，不同于传统物理设备，虚拟网络设备分布在云平台各个节点，面临着更多的安全风险，一旦这些风险问题发生，很可能破坏租户与租户之间的网络隔离性，导致租户不能完全信任云服务提供商。针对当前云平台多租户网络隔离问题，业内展开了许多研究。目前，以Openstack为代表的主流云平台利用网络虚拟化技术实现多租户的网络隔离，如Openstack最新版本网络组件Neutron使用OpenvSwitch(OVS)结合VLAN等机制实现多租户的二层网络隔离，利用Iptables防火墙和NetworkNameSpace机制实现多租户三层网络隔离。严立宇等又基于上述Openstack多租户网路隔离解决方案存在的单点故障问题，提出了一种分布式多租户网络隔离解决方案，即将租户的虚拟路由器、交换机以及防护墙设备部署到每个计算节点来实现高可用的云平台多租户网络隔离。RuozhouYu等则基于Openstack多租户网络隔离存在的管理配置的弊端，提出了NeFuCloud方案，基于NFV技术来构建多租户的隔离网络。KaiLi等则提出了基于SDN的多租户虚拟网络定制方案，采用网络分片的方式实现云平台多租户的网络隔离。上述解决方案虽然提出了解决云平台多租户网络隔离问题的各项方法，但没有充分考虑这些虚拟网络设备本身存在的安全风险，一旦风险发生，租户的私有网络很可能被恶意渗透，例如，一个恶意的管理员通过Hypervisor创建一台VM挂载到租户虚拟网桥，继而渗透进租户网络，影响租户私有网络内的VM隔离性，而租户不能发现该可疑虚拟机。基于这种安全风险考虑，租户不能完全信任云平台提供的网络隔离环境。技术实现要素：针对上述问题，本发明采用一种基于云平台的多租户网络拓扑重构方法，从云平台底层重构实时运行环境中的多租户网络拓扑，直观表达云平台多租户网络隔离状态。本发明采用的技术方案为基于云平台的多租户网络拓扑重构方法，该方法的思路如下：在云平台各个计算节点上，通过Hypervisor获取对应节点上运行的所有VM信息，之后对获取的所有VM信息进行遍历，得到每个VM的网络连接信息，包括MAC地址以及其挂载的网桥信息；另一方面，通过底层设备命令获取每个计算节点的网桥信息，网桥信息包括传统网桥和OVS网桥，之后根据获取的VM信息和网桥信息，确定VM和各个网桥之间的连接关系，重构该计算节点的VM网络拓扑，形成整体的实时运行环境中的云平台多租户网络拓扑。该方法的步骤包括：步骤一，读取云平台相关网络配置和租户信息，确定云平台采用的网络模式和各个租户预先规划的网络拓扑。步骤二，调用各个计算节点相关虚拟化平台API，获取各个计算节点上所有的VM，遍历所有VM，获取配置文件，依据配置文件解析出各个VM的网络连接信息，包括该VM各个网络接口的MAC地址信息，该接口挂载的网桥信息以及在该网桥对应的连接接口信息。步骤三，通过底层设备命令获取各个计算节点部署的网桥信息，网桥分为两类：传统网桥和OVS网桥，获取的信息包括网桥的名称、网桥的所有接口名称和网桥的类别。步骤四，步骤二中获取的VM网络连接信息和步骤三获取的网桥信息对应，即确定VM和网桥的连接关系，依此，建立计算节点上所有VM与网桥的连接关系，以及网桥和网桥之间的连接关系，即重构出该计算节点上的网络拓扑树。步骤五，在某一计算节点，尝试通过虚拟化平台API创建一台VM，并私自挂载到某个租户VM所挂载的网桥上，重新进行步骤二至步骤五，重构计算节点租户拓扑，并与步骤一中获取的该租户预先规划的云平台网络拓扑进行对比，看重构的租户拓扑是否能发现管理员私自创建的可疑VM。通过与云平台提供给租户的网络隔离拓扑对比，本发明的方法能够有效地发现云平台租户网络拓扑中存在的可疑VM，并且提供给租户一份直观友好的实时云平台多租户网络拓扑，便于用户对该云平台提供的基础网络隔离环境做出可信性判断。附图说明图1是本发明所基于的云平台多租户网络隔离场景图；图2是本发明所涉及的云平台多租户网络拓扑重构方法流程图。具体实施方式下面结合附图和具体实施方式对本发明做进一步的说明。当前主流云平台针对多租户网络隔离的解决方案通常如图1所示。在该场景下，承载租户底层网络的通常是虚拟交换机(VirtualSwitch)和传统网桥(NetworkBridge)设备，这些设备通常和租户的虚拟机部署在计算节点，通过VLAN划分等方式实现租户的底层网络隔离。与传统模式相比，在这样一个分布式的云平台多租户网络隔离架构下，原来的可信边界彻底被打破了，任何一个点发生安全风险，都可能打破多租户的网络隔离状态。本发明实施将基于该场景，底层采用Openstack云平台部署租户网络拓扑，网络组件采用Neutron组件，计算节点虚拟化环境基于Libvirt和KVM构建，网络采用VLAN模式。基于云平台的多租户网络拓扑重构方法，整个流程如图2所示。步骤一，获取Openstack云平台网络相关配置文件，包括/etc/nova/nova.conf和/etc/neutron/neutron.conf，从中读取相关网络配置，再根据配置信息获取云平台预先给租户规划的网络拓扑。步骤二，通过Libvirtvirsh相关命令采集VM信息，virshlist–all拿到该计算节点上所有的VM。virshdumpxmlinstance-name拿到VM详细信息，如下：其中interface部分即为VM的MAC地址及其连接的网络设备信息，据此定义VM数据抽象如下：其中name即为该VM名称，macs表示VM的网络接口，为一个数组，数组项为各个网络接口的具体信息：MAC_ADDRi标识该网络接口的MAC地址，BRIDGE_NAME为该接口挂载的网桥信息，NETWORKj表示该接口所属的私有网络信息，这里用VLAN_ID来代表一个二层的私有网段信息，status表示该VM的当前状态或RUNNING,STOP等。步骤三，Openstack环境下，虚拟网桥涉及两类，一类是传统的NetworkBridge，另外一类是OpenvSwitch下的各类OVS网桥，典型的如br-int等。Openstack通过借助这两类网桥实现多租户网络拓扑构建。本次对网桥信息的采集基于底层的设备命令来获取，其中NetworkBridge网桥信息利用brctlshow命令获取，OVSBridge网桥信息采用OVS-vsctlshow命令获取。定义网桥信息数据抽象如下：其中name为该网桥的名称，与VirtualMachine挂载的BRIDGE_NAME对应，bridge_type表示该网桥的类型，是network_bridge或者OVS_bridge，ports表示该网桥上的接口，用一个数组表示，INTERFACEi则表示该网桥每个接口的信息。步骤四，根据VM与bridges之间的连接关系，以及bridges之间的连接关系，重构云平台多租户网络拓扑树。设计树节点类表1：表1：云平台多租户网络拓扑树节点UML描述其中name为该节点名称，该节点是一台VM，或者是一个NetworkBridge,或者是一个OVSBridge，childlist是与该节点具有连接关系的下一层节点，为一个数组项；成员方法addChild为增加该树节点子节点的方法。之后设计云平台多租户网络拓扑类，如表2：表2：云平台多租户网络拓扑重构类UML描述其中成员变量tree_root为该树的跟节点，vms为该树包含的各个VM节点，lbs和obs分别表示该树中的NetworkBridge和OVSBridge节点，均为数组；成员函数createTopology为重构云平台多租户网络拓扑树的方法，displayTopology为打印该树的方法，topologyToXML为将该拓扑树转换成XML文件保存的方法。整个createTopology方法过程如下：(1)遍历obs和lbs，对其中每一个数组项构建TreeNode实例。(2)遍历vms各项，判断该VM每一个mac对应的BRIDGE_NAME是否存在于obs或者lbs中，如果存在，则对该VM网络接口创建TreeNode实例，并且调取该接口对应的网桥节点的addChild方法，继而成为该网桥的下一层子节点；通过如上遍历，继而建立了VMs和各个网桥的拓扑连接关系。(3)通过网络设备连接命令获取obs和lbs各个网桥之间的连接关系，如果有连接，则调用obs相应树节点的addChild方法，添加相应的lbs网桥为子节点。(4)调用tree_root的addChild方法，添加各个obs网桥作为子节点，至此从上到下形成一棵完整的租户拓扑树步骤五，具有管理员权限的用户尝试通过Libvirt创建一台VM，并且将其挂载到某个网桥，采用该方法重新收集拓扑树信息，并与步骤一获取的云平台提供的租户拓扑进行对比。通过对比发现，本方法能够有效地发现该管理员私自创建到租户拓扑的VM，而云平台提供的租户拓扑里并无该VM。同时在实施过程中，记录本方法在重构云平台多租户网络拓扑所占用的CPU和内存资源，结果是在每个计算节点平均有12台VM的情况下，拓扑重构对CPU利用率不超过1％，内存使用小于35M。因而可以认为，通过云平台多租户网络拓扑重构，能够有效表示云平台多租户网络隔离状态的同时，不会对云平台造成过多的资源消耗。当前第1页1 2 3 当前第1页1 2 3