宣告：
本部落格歡迎轉發，但請保留原作者資訊!
新浪微博：@孔令賢HW；
部落格地址：http://blog.csdn.net/lynn_kong
內容系本人學習、研究和總結，如有雷同，實屬榮幸！

更新記錄：

2013.06.27 增加在ovs plugin使用安全組以及在Nova使用Neutron安全組時需要的配置說明

1.介紹

在Grizzly版中，安全組從Nova移植到了Quantum。有幾個特性：
1. 後向相容。從F版升級到G版，仍然可以用F版Nova的API進行安全組的操作。
2. 同時支援ingress和egress（即入口和出口規則），但通過Nova API僅支援ingress規則。
3. 安全組作用於Quantum中的Port，而不再是原來Nova中的虛擬機器。
4. 允許在虛擬機器執行期修改安全組
5. 每個租戶（tenant, 在G版的Keystone中又叫project）都有預設的安全組

安全組行為：
1. 如果沒有指定ingress規則，則不允許任何資料包進入；
2. 如果沒有指定egress規則，則不允許任何資料包出去；
3. 新建一個安全組時，會自動增加一條規則，允許所有的資料包出去
4. 每個租戶的預設安全組，允許租戶的虛擬機器之間內部通訊；允許租戶虛擬機器對外通訊；不允許外界資料流進入租戶的虛擬機器。

2.使用流程

1. Quantum
a. 建立一個port
b. 給port關聯一個安全組
c. 如果要建立的虛擬機器有多個網絡卡，那麼可以重複a,b
d. 建立虛擬機器，指定上面建立的port
e. 現在，你有了一個虛擬機器，並且虛擬機器上的網絡卡通訊受安全組規則的約束

2. Nova
a. 使用者要通過Nova的API建立一個虛擬機器，並且為虛擬機器關聯安全組
b. Nova呼叫Quantum建立port，為port關聯安全組
c. Nova使用port的資訊建立虛擬機器

3.實現

其實，Quantum的安全組實現（在LinuxBridge和OVS上），與F版的實現基本一樣，都是通過iptables。

G版中為安全組增加了兩個新的資源：security_group和security_group_rule，同時為Port增加一個新的屬性：security_group。為了保證相容，在建立network、建立port、建立安全組時都會先看租戶是否有預設的安全組，如果沒有則新建，並且在新建的預設安全組中同時會新建兩條規則：允許同一個安全組內的成員通訊；允許安全組內的成員對外通訊。對於租戶新建立的安全組也會做同樣的事情。

先來看下安全組相關的類的設計，以OVS安全組實現為例：

server端有三個主要的類：
OVSBridgePluginV2：介面業務處理
AgentNotifierApi：是plugin與agent通訊的幫助類
OVSRpcCallbacks：負責處理agent的請求
而藍色的框是上述三個類為了實現安全組功能需要繼承的父類。

agent端有兩個主要的類：
OVSQuantumAgent：處理server端發來的請求
OVSPluginApi：是agent與plugin通訊的幫助類
同樣，藍色的框是上述兩個類為了實現安全組功能需要實現的父類。SecurityGroupAgentRpcMixin是SecurityGroupAgentRpcCallbackMixin類需要呼叫的類，它又會呼叫SecurityGroupServerRpcApiMixin類向server端傳送訊息。

對於建立安全組以及建立安全組規則來說，server端只是在資料庫中記錄資料而已，不涉及與agent的通訊。真正涉及plugin與agent通訊的操作有以下幾個：

3.1. 指定安全組建立虛擬機器（不指定port）

這裡要注意的是，如果指定port，同時又指定了安全組，那麼只會使用port上的安全組規則，而忽略使用者指定的安全組。也就是說，如果指定了安全組建立虛擬機器，那麼就不要指定port。

建立虛擬機器，如果不指定port，那麼Nova會自動呼叫Quantum的建立Port介面，在指定的network上（如果不指定network，則在租戶的所有network上，包括共享network）建立port，同時指定安全組資訊。這樣Quantum在建立port時就會記錄port與安全組的關聯關係。同時，呼叫上面server端藍色框SecurityGroupAgentRpcApiMixin類的security_groups_member_updated方法，向名為“q-agent-notifier-security_group-update”，型別為fanout的exchange上傳送訊息，訊息的引數就是安全組標識。

所有的quantum l2 agent都會收到該訊息，是在上圖agent端藍色框SecurityGroupAgentRpcCallbackMixin類中處理，該類又呼叫了SecurityGroupAgentRpcMixin物件進行處理。處理邏輯是這樣的：如果該節點上所有port都沒有引用入參中的安全組，不處理；否則，就要重新重新整理本節點的iptables規則。那麼，根據什麼重新整理呢？

其實，agent又會呼叫上述agent端藍色框SecurityGroupServerRpcApiMixin物件的security_group_rules_for_devices方法，向server端獲取本機ports最新的安全組規則資訊，即由上述server端藍色框SecurityGroupServerRpcCallbackMixin物件處理。

整個處理流程就是按照上圖的箭頭指示進行。

3.2. 建立/刪除port

其實上述建立虛擬機器的流程中已經包含了建立port的過程。而刪除port的過程與建立port是一樣的。流程圖如下：

3.3. 更新port

更新port與port的建立和刪除走的不是一個通道。更新port走的是server與agent的port_update介面（而不是security_groups_member_updated）。而在agent端的port_update方法中，其實還是呼叫agent端藍色框SecurityGroupServerRpcApiMixin物件的security_group_rules_for_devices方法更新本機的iptables規則。

3.4. agent發現有新的device

當agent發現本節點有新的device出現時，也會呼叫agent端藍色框SecurityGroupServerRpcApiMixin物件的security_group_rules_for_devices方法更新本機的iptables規則。流程圖如下：

3.5. 新增/刪除安全組規則

新增/刪除安全組規則時，呼叫上面server端藍色框SecurityGroupAgentRpcApiMixin類的security_groups_rule_updated方法，向名為“q-agent-notifier-security_group-update”，型別為fanout的exchange上傳送訊息，訊息的引數就是安全組標識。agent的處理參見建立虛擬機器時的處理，只是判斷條件略有不同，具體請自行閱讀程式碼。

4、配置

使用ovs plugin時，要想安全組功能生效，需要在plugin的配置檔案中配置：

[SECURITYGROUP]
firewall_driver=quantum.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver

否則，ovs plugin不會支援security-group extension的（預設的配置是quantum.agent.firewall.NoopFirewallDriver）。

在Nova中要使用Neutron的安全組功能，也需要在nova.conf中配置：

[DEFAULT]
security_group_api=quantum

同時，在Nova中要配置：firewall_driver = nova.virt.firewall.NoopFirewallDriver（預設配置：firewall_driver=nova.virt.libvirt.firewall.IptablesFirewallDriver）

5.與其它雲平臺安全組功能對比

5.1. Security Group for Amazon VPC

使用Amazon的VPC功能，當把虛擬機器加入一個VPC時，可以指定虛擬機器所屬的安全組（最多指定5個，注意區分安全組規則與子網規則）。如果不指定，虛擬機器會關聯一個預設的安全組。

簡單說一下安全組規則和子網規則的區別：

安全組規則	Network ACL
作用在虛擬機器層面（第一層防護）	作用在子網(subnet)層面（第二層防護）
只能設定“允許”規則	支援“允許”規則和“禁止”規則
允許返回的資料包，無視規則	僅允許返回規則允許的資料包
在允許資料包通過之前會檢測全部規則	在允許資料包通過之前會按順序檢測規則
在建立虛擬機器階段指定安全組，或在虛擬機器執行時動態關聯安全組	自動作用在子網中的虛擬機器上

以一個圖示可能會表達得更清楚：


VPC中安全組的約束：
1. 在一個VPC中可以建立最多100個安全組，每一個安全組中可以新增最多50條規則。如果你想為虛擬機器新增超過50條的安全組，那麼只能為虛擬機器關聯最多不超過5個安全組；
2. 只能指定“允許通過（allow）”的規則
3. 支援ingress和egress
4. 預設情況下，安全組不允許進入資料包
5. 預設情況下，安全組允許所有資料包出去
6. 同一個安全組中的虛擬機器之間預設相互不能通訊（而預設安全組除外，因為預設安全組中有相應的允許規則）
7. 虛擬機器建立之後，可以動態的修改其所屬的安全組
8. 每個VPC中都有一個預設的安全組，而這個預設安全組的行為是：a. 不允許外來資料包進入（本安全組內虛擬機器之間通訊除外）；b. 允許出去的資料包；c. 安全組內虛擬機器之間互通。當然，可以通過介面改變預設安全組的行為。

說了這麼多，這裡說的安全組是指VPC內的安全組，與普通EC2場景中使用的安全組是不同的概念，而且相互之間也不能引用。它們之間的區別：

EC2場景	VPC場景
每個使用者在每一個region下可以建立最多500個安全組	每個使用者在每個VPC中可以建立最多100個安全組
每個安全組最多有100條規則	每個安全組最多有50條規則
僅支援ingress規則	同時支援ingress和egress規則
虛擬機器關聯的安全組數目無上限	每個虛擬機器最多關聯5個安全組
可以引用其他帳戶的安全組	只能引用你VPC中的安全組
虛擬機器建立後，不能修改它的安全組	可動態修改
增加規則時，不必指定協議（協議僅支援TCP，UDP，ICMP）	增加規則時，協議是必選的，且支援標準協議埠

VPC中安全組命令和API：

5.2. CloudStack Securitygroup

在CloudStack 3.0.3 -3.0.5中，安全組只能使用在basicnetworking中，後續的版本中才能在advancednetworking中使用。其實在advancednetworking中，可以通過建立不同的guest network來達到網路隔離的目的。

租戶的預設安全組的規則：1. 允許所有資料包出去；2. 不允許任何資料包進入。預設安全組的行為也可以修改。
租戶建立的安全組數量無上限，安全組的規則數目無上限，虛擬機器關聯的安全組數量也無上限。
虛擬機器關聯安全組後，不能退出該安全組。
可以在虛擬機器執行或停止狀態修改安全組規則，即時生效。