Openstack Nova Security Group——安全组之架构篇

哈，又回来了！

公司同事说不要只停留在逻辑层，你要对跑在你程序底下的数据流也要非常的清楚。但是这里还是先介绍一下逻辑层，在代码的角度看是如何实现这个功能的，关于底层的数据流，还需要哦酝酿一段时间，之后会再总结一篇底层数据流的文章，真难为我了！

一、什么是安全组

安全组，翻译成英文是 security group。安全组是一些规则的集合，用来对虚拟机的访问流量加以限制，这反映到底层，就是使用iptables，给虚拟机所在的宿主机添加iptables规则。

可以定义n个安全组，每个安全组可以有n个规则，可以给每个实例绑定n个安全组，nova中总是有一个default安全组，这个是不能被删除的。创建实例的时候，如果不指定安全组，会默认使用这个default安全组。

现在nova中安全组应该会移到quantum中，并且会增加对虚拟机外出流量的控制。现在nova中的安全组只是对进入虚拟机的流量加以控制，对虚拟机外出流量没有加以限制。

关于security group的详细使用，见这里

二、整体架构

Security Group在nova中是通过扩展的形式实现的，关于Nova API的扩展又是一大篇的文章才能介绍的清楚，这里就不说了。其实感觉到REST API是整个openstack项目中非常重要的组成部分，只有理解了REST API才能更好的掌握openstack。真是长见识了，原来API还可以是这样。

nova 中的API扩展机制非常的好，可以让开发人员很方便的定制自己想要的功能，只要添加一个文件到那个目录中，工作就完成了80%了吧。

安全组就是这样一个扩展，位于nova/api/openstack/compute/contrib/security_groups.py中，还是先来看一下实现它的静态类图吧：

每一个扩展文件中都必须有一个和文件名同名的类，比如这里的类就是Security_groups，这个类就是把REST API需要的controller和wsgi_action聚合在一起，加载扩展的时候，就是加载的这个类，controller和wsgi_action中定义了对资源的各种操作，controller定义了show, create, index, delete等等操作，action定义了一些除了CIDR之外的额外的操作：

SecurityGroupController类定义了security group的操作，也即对安全组，这个“组”的增删查改操作。

SecurityGroupRulesController类定义了对组中的规则的操作。

ServerSecurityGroupController类定义了对和实例绑定的安全组的查询操作。

SecurityGroupActionController类中定义了把实例从安全组中添加/删除。

nova中有两个非常重要的组件，一个是db，一个是message queue，db用来记录各种状态，message queue用来在各个服务和各个节点之间传递消息，这种机制，在这里可以得到非常好的体现。这些操作被封装成为了一个类：SecurityGroupAPI，定义在了compute/api.py中，看代码，在E版中这些代码是和compute.API混在一起的，到了F版将和Security Group相关的代码抽取出来，封装成了SecurityGroupAPI，这个类主要是封装了对db的操作和rpc的操作。

安全组在架构上的实现想想其实也很简单，也没什么架构，基本上openstack中所有的组件都是这一个模式，db记录状态，然后发送rpc消息，调用一个第三方包去做xxx工作，然后再用db记录状态。

compute_rpcapi.SecurityGroupAPI是用来发送cast/call消息的，主要是用来在安全组更新之后刷新规则。

三、进一步深入

在由API层发送rpc消息之后，API层的工作就算做完了，接下来就到了compute.ComputeManager中了，他们之间的依赖关系如下图：

ComputerManager中有一个driver，都知道这个driver默认的就是libvirt，还有就是init_host()方法比较重要，每个Manager都有这样一个方法，是相对应的服务在启动的时候调用的，用来进行一些初始化，主要做的工作是对网络进行初始化，建立一些初始的chain和rule，这在下一篇文章中会详细讲到。

最下面的是linux_net，这可以说是最接近底层的代码层了，在它里面封装了对Iptables的各种抽象，具体看下类图：

OK，就暂时深入到这里吧。

四、功能测试

http://paste.openstack.org/show/33422/