前言
從7.8號開始分析OpenStack已經有兩週了，原本計劃一個月分析完Neutron和Nova的，但是捋了下Nova的虛擬機啓動流程，尤其是看到popsuper1982仁兄寫得虛擬機啓動的100個知識點，大概流程是清楚了，但是我沒辦法再去逐一深究，所以想把這裏面再提取幾個我關注的知識點研究一下。先借用一下網上的兩張圖：
虛擬機啓動的100個知識點
虛擬機啓動的整體流程
這裏面我比較關注的幾個問題：
- 安全認證機制，如何確保客戶端的訪問時可信的。（我並不做安全，只是純屬興趣，畢竟互聯網金融時代我也想了解下我的財富是否安全^_^）
- 虛擬機調度算法（類似於進程調度，這個任務是操作系統的核心）
- 虛擬機在整個流程中的狀態遷移
- HA機制涉及的技術，包括事務，分佈式技術等
- Hypervisor層的接口與調用
- 虛擬機熱遷移如何實現
- OAM：OpenStack後臺運行的週期性任務
一口氣列了七個問題，我想到下週能徹底寫完就算比錯，因爲Neutron的部分我有些底子。再用一週應該可以分析完成。
安全認證
我不是搞安全的，在我看來，安全認證的範圍在於如何證明你媽是你媽，也就是當一個Restcall到來的時候，如何保障消息來源的可靠性以及消息的完整性，消息來源的可靠性的意思是Restcall的來源是經過認證的註冊用戶，而不是第三方黑客；消息的完整性是指消息在傳遞的過程中沒有被修改。注意，這裏面沒有涉及消息的加密技術，這是另一個範疇，加密是保障消息在傳遞過程中第三方無讀取權限（比如網上交易裏涉及的密碼等等）。
Token是什麼
一般來說，Token是通過提供有效的用戶名/密碼組合提供給用戶的一段數據。另外，與Token密切相關的是它的有效期（通常是幾小時甚至幾分鐘）。Client可以緩存Token並將其注入到OpenStack API請求中。OpenStack API端點將令牌從用戶請求中取出，並通過KeyStone後端進行驗證，從而確認調用的合法性。
我們現在把注意力放在兩種Token生成方式：通用唯一標識符（UUID）和公共密鑰基礎設施（PKI）的標識
UUID
基於提供的用戶名/密碼對：
- KeyStone將做以下工作：
- 生成一個UUID令牌。
- 將UUID令牌存儲在後端。
- 發送一份拷貝的UUID令牌返回給客戶端。
- 客戶機將緩存令牌。
- 然後客戶端會把UUID附在每個API調用上。
- 在每一個用戶的請求，API端點會送這個UUID回到Keystone驗證。
- Keystone將UUID和它的認證後端匹配（檢查UUID字符串、日期）。
- KeyStone將返回“成功”或“失敗”消息到API端點。
從上面的圖表中可以看到，對於每個用戶調用，API端點都需要使用KeyStone服務進行聯機驗證。想象成千上萬的Client執行VM List、網絡創建等等操作。這種設計導致了大量流量被導向了KeyStone造成單點故障。事實上，在生產中，Keystone被證明是負載最重的OpenStack服務之一，但Grizzly版本之後就採取了PKI方式來解決這個問題。
背景知識：非對稱加密
採用非對稱加密算法，公鑰獲取的可靠性就非常重要，獲取到正確的公鑰，後續的工作就成功了一半。另一半是保障數據的完整性，這個是通過數據簽名實現的，怎麼樣才能保障獲取到正確的公鑰呢？
我們第一反應可能會想到以下的兩個方法：
- a)把公鑰放到互聯網的某個地方的一個下載地址，事先給“客戶”去下載。
- b)每次和“客戶”開始通信時，“服務器”把公鑰發給“客戶”。
但是這個兩個方法都有一定的問題，
對於a)方法，“客戶”無法確定這個下載地址是不是“服務器”發佈的，你憑什麼就相信這個地址下載的東西就是“服務器”發佈的而不是別人僞造的呢，萬一下載到一個假的怎麼辦？另外要所有的“客戶”都在通信前事先去下載公鑰也很不現實。
對於b)方法，也有問題，因爲任何人都可以自己生成一對公鑰和私鑰，他只要向“客戶”發送他自己的私鑰就可以冒充“服務器”了。示意如下：
“客戶”->“黑客”：你好 //黑客截獲“客戶”發給“服務器”的消息
“黑客”->“客戶”：你好，我是服務器，這個是我的公鑰 //黑客自己生成一對公鑰和私鑰，把公鑰發給“客戶”，自己保留私鑰
“客戶”->“黑客”：向我證明你就是服務器
“黑客”->“客戶”：你好，我是服務器 {你好，我是服務器}[黑客自己的私鑰|RSA] //客戶收到“黑客”用私鑰加密的信息後，是可以用“黑客”發給自己的公鑰解密的，從而會誤認爲“黑客”是“服務器”
因此“黑客”只需要自己生成一對公鑰和私鑰，然後把公鑰發送給“客戶”，自己保留私鑰，這樣由於“客戶”可以用黑客的公鑰解密黑客的私鑰加密的內容，“客戶”就會相信“黑客”是“服務器”，從而導致了安全問題。這裏問題的根源就在於，大家都可以生成公鑰、私鑰對，無法確認公鑰對到底是誰的。 如果能夠確定公鑰到底是誰的，就不會有這個問題了。例如，如果收到“黑客”冒充“服務器”發過來的公鑰，經過某種檢查，如果能夠發現這個公鑰不是“服務器”的就好了。
解決這個問題其實就不是技術問題了，需要一個權威機構來授權數字證書，它可以解決我們上面的問題。先大概看下什麼是數字證書，一個證書包含下面的具體內容（證書相當於協議的控制面，會定義後續交互的算法和公鑰等）：
◆CA (證書的發佈機構)
指出是什麼機構發佈的這個證書，也就是指明這個證書是哪個公司創建的(只是創建證書，不是指證書的使用者)。對於上面的這個證書來說，就是指”SecureTrust CA”這個機構。
◆Valid from , Valid to (證書的有效期)
也就是證書的有效時間，或者說證書的使用期限。 過了有效期限，證書就會作廢，不能使用了。
◆Public key (公鑰)
這個我們在前面介紹公鑰密碼體制時介紹過，公鑰是用來對消息進行加密和解密的。
◆Subject (主題)
這個證書是發佈給誰的，或者說證書的所有者，一般是某個人或者某個公司名稱、機構的名稱、公司網站的網址等。 對於這裏的證書來說，證書的所有者是Trustwave這個公司。
◆Signature algorithm (簽名所使用的算法)
就是指的這個數字證書的數字簽名所使用的加密算法，這樣就可以使用證書發佈機構的證書裏面的公鑰，根據這個算法對指紋進行解密。指紋的加密結果就是數字簽名。
◆Thumbprint, Thumbprint algorithm (指紋以及指紋算法)
這個是用來保證證書的完整性的，也就是說確保證書沒有被修改過，其原理就是在發佈證書時，發佈者根據指紋算法(一個hash算法)計算整個證書的hash值(指紋)並和證書放在一起，使用者在打開證書時，自己也根據指紋算法計算一下證書的hash值(指紋)，如果和剛開始的值對得上，就說明證書沒有被修改過，因爲證書的內容被修改後，根據證書的內容計算的出的hash值(指紋)是會變化的。 注意，這個指紋是數據的指紋，並不是代表客戶端或服務器端的指紋。
注意，爲了保證安全，在證書的發佈機構發佈證書時，證書的指紋和指紋算法，都會加密後再和證書放到一起發佈，以防有人修改指紋後僞造相應的數字證書。這裏問題又來了，證書的指紋和指紋算法用什麼加密呢？他們是用證書發佈機構的私鑰進行加密的。可以用證書發佈機構的公鑰對指紋和指紋算法解密，也就是說證書發佈機構除了給別人發佈證書外，他自己本身也有自己的證書。證書發佈機構的證書是哪裏來的呢？？？這個證書發佈機構的數字證書(一般由他自己生成)在我們的操作系統剛安裝好時(例如windows xp等操作系統)，這些證書發佈機構的數字證書就已經被微軟(或者其它操作系統的開發機構)安裝在操作系統中了，微軟等公司會根據一些權威安全機構的評估選取一些信譽很好並且通過一定的安全認證的證書發佈機構，把這些證書發佈機構的證書默認就安裝在操作系統裏面了，並且設置爲操作系統信任的數字證書。這些證書發佈機構自己持有與他自己的數字證書對應的私鑰，他會用這個私鑰加密所有他發佈的證書的指紋作爲數字簽名。
說白了，要想具備CA資質，又需要到更權威的機構去認證，而這些更權威的機構是已經默認在操作系統中安裝了其公鑰證書。所以在初始階段，Client會拿着Server端的證書去權威機構鑑定是否是對方，而Server端會拿着Client的證書去自己的CA機構Keystone驗證可靠性。
證書的發佈機構
前面已經初步介紹了一下證書發佈機構，這裏再深入討論一下。
其實所有的公司都可以發佈證書，我們自己也可以去註冊一家公司來專門給別人發佈證書。但是很明顯，我們自己的專門發佈證書的公司是不會被那些國際上的權威機構認可的，人家怎麼知道你是不是個狗屁皮包公司？因此微軟在它的操作系統中，並不會信任我們這個證書發佈機構，當應用程序在檢查證書的合法信的時候，一看證書的發佈機構並不是操作系統所信任的發佈機構，就會拋出錯誤信息。也就是說windows操作系統中不會預先安裝好我們這個證書發佈機構的證書，不信任我們這個發佈機構。
不受信任的證書發佈機構的危害
爲什麼一個證書發佈機構受不受信任這麼重要？我們舉個例子。假設我們開了一個狗屁公司來爲別人發佈證書，並且我和微軟有一腿，微軟在他們的操作系統中把我設置爲了受信任的證書發佈機構。現在如果有個小公司叫Wicrosoft 花了10塊錢讓我爲他們公司申請了一個證書，並且公司慢慢壯大，證書的應用範圍也越來越廣。然後有個奸商的公司JS Company想冒充Wicrosoft，於是給了我￥10000，讓我爲他們頒佈一個證書，但是證書的名字(Subject)要寫Wicrosoft，假如我爲了這￥10000，真的把證書給了他們，那麼他們以後就可以使用這個證書來冒充Wicrosoft了。
如果是一個優秀的證書發佈機構，比如你要向他申請一個名字叫Wicrosoft的證書，它會讓你提供很多資料證明你確實可以代表Wicrosoft這個公司，也就是說他回去覈實你的身份。證書發佈機構是要爲他發佈出的證書負法律責任的。
到這裏，你可能會想，TMD，那我們自己就不能發佈證書嗎？就一定要花錢去申請？當然不是，我們自己也可以成立證書發佈機構，但是需要通過一些安全認證等等，只是有點麻煩。另外，如果數字證書只是要在公司內部使用，公司可以自己給自己生成一個證書，在公司的所有機器上把這個證書設置爲操作系統信任的證書發佈機構的證書(這句話仔細看清楚，有點繞口)，這樣以後公司發佈的證書在公司內部的所有機器上就可以通過驗證了(在發佈證書時，把這些證書的Issuer(發佈機構)設置爲我們自己的證書發佈機構的證書的Subject(主題)就可以了)。但是這只限於內部應用，因爲只有我們公司自己的機器上設置了信任我們自己這個所謂的證書發佈機構，而其它機器上並沒有事先信任我們這個證書發佈機構，所以在其它機器上，我們發佈的證書就無法通過安全驗證。
PKI方式
在PKI方式下，KeyStone已經成爲一個CA（認證授權）機構，PKI 的本質就是基於數字簽名，Keystone 用私鑰對 token 進行數字簽名，各個 API server 用公鑰在本地驗證該 token。也就是說通過這種方式來實現單點登錄（用戶只需要登錄一次就可以訪問所有相互信任的應用系統）。當然這裏如何確保安全（比如黑客截獲這個Token冒充客戶端發送請求，當然這裏會有一個Token過期時間），我也不太清楚，只是當前已經在使用這種方式，是否安全具體做安全的人可以告知一下。這裏的Token是通過Service catalog，User roles，Metadata等消息來生成的
總結一下：
如何確保消息源的可靠性？ 通過第三方權威機構認證的CA機構纔有授予證書的權利，而這些第三方權威機構在操作系統默認已經安裝，在初始階段，Client會拿着Server端的證書去權威機構鑑定是否是對方，而Server端會拿着Client的證書去自己的CA機構Keystone驗證可靠性。
如何確保數據的完整性？ 通過數據簽名算法，首先對數據進行Hash算法生成指紋，然後用公鑰或者私鑰加密生成數字簽名，接收方拿到數據後使用私鑰解密數字簽名，同時使用相同的Hash算法對數據生成指紋進行比對。
如何確保數據是保密的，第三方無查看權限？ 交互雙方在互相認定證書之後會使用公私鑰加密約定消息體的對稱加密算法和公鑰，這個過程是客戶端來發起的，服務器端不允許這個操作。
總而言之，證書類似一個協議控制面，用來做消息源可靠性的認定以及數據完整性的算法約定，後續的交互就會用上證書約定的公鑰和指紋算法。消息體的保密性是無法確保的。需要靠另外的數據加密算法。
參考文獻：
http://www.cnblogs.com/popsuper1982/p/3800235.html
http://blog.sina.com.cn/s/blog_44ee37cd01016r1h.html