OpenStack關鍵技術系列：KeyStone鑒權認證系統詳解

今天，我們深入到每一個服務組件詳細的來說說OpenStack了，接下來還是從比較重要的Keystone組件服務說起。

先來舉幾個平時能夠看到的例子:

業務系統認證示意圖

上面的這個圖所示的一般常用於企業多個業務系統的模型認證。用戶端訪問不同的業務系統，採用不同的username和password，每個業務系統有獨立的用戶信息庫。這樣多個的業務系統認證缺陷也是顯而易見的，用戶信息的維護以及統一認證和許可權控制都面臨著問題。

統一認證業務系統示意圖

上面的這個圖是針對前一者，將各個業務系統的用戶信息進行集中，這樣各個系統就可以去一個地方去取用戶信息而在本地去做對比驗證用戶正確與否。這樣雖然解決了一部分用戶信息維護和統一管理的問題，但是還是存在各個業務系統之間」各自為政」自己進行獨立許可權控制，無法進行統一標準的許可權管理控制。

Openstack架構組件認證流示意圖

在來看keystone方式，上一篇文章說過了，openstakc整體架構也是遵循著」高內聚、低耦合」設計的，組件內部相關部件關聯形成組件的功能，組件之間有標準的Endpoint可以直接調用。

而Openstack整體與多個業務系統整體也不太一樣，拿上圖來說，每個Openstack服務組件就相當於一個業務系統，比如:nova-OA系統、glance-ERP系統、neutron-CRM系統，可以完成相應的操作。

Nova維護虛擬機的生命周期，虛擬機創建、啟動、重啟、註銷、刪除等等；Glance維護虛擬機原生鏡像，Windows Server 2008 R2、RHEL7、Centos 6等等。

Neutron則維護著關於虛擬機全部的網路信息，比如:私有網路，子網劃分，ACL等等。但同時不一樣的一點是，企業的各個業務系統之間其實是可以互相獨立完成一個企業業務的信息流整合，兩者之間可以沒有任何關係(可以仔細看看圖1和圖2紅色字體)

而Openstack的各個組件之間則不是這樣，單獨的使用keystone、nova、glance、neutron是不可以的，因為這些組件是依託整個openstack工程架構存在的，屬於強關聯，無法單獨使用。

當然了，你可以單獨的選擇每一個服務組件的底層實現技術，將其挑選出來而進行相關Coding研發成產品對市場推廣也是可以作為雲的解決方案的，比如我上一家公司，就是將維護虛擬機生命周期管理的計算虛擬化使用開源的KVM、而維護虛擬機數據的分散式存儲使用開源的GlusterFS、解決虛擬機跨物理節點通信則使用VxLAN技術，以上的這樣也是可以的。但是，我們不能說單獨的使用nova做一個伺服器虛擬化產品，這樣是錯誤的。

所以，在整體有強關聯性的組件之間，要實現3A(認證Authentication、授權Authorization、計帳Accounting)則就是keystone在整體openstack工程架構出現的意義了。

從上圖中可以看到，用戶首先提交的是用戶名和密碼(圖中綠色標記)，然後Keystone返回Token憑證(圖中綠色標記)，然後從用戶發出創建VM虛擬機一直到VM創建完成的全部過程中，使用都是使用Token憑證進行用戶身份認證與許可權控制(圖中橙色標記)，同時每次均為各個服務組件去跟Keystone請求驗證(圖中灰色標記)，對於前端用戶來說完全透明。

而新建虛擬機是由nova服務組件主要負責操控，所以nova會向相關的服務組件發出相關操作請求(圖中藍色標記)，以此來完成虛擬機創建的任務。

以上為keystone的簡單介紹，下面我們詳細的說道說道。

Keystone發布時間

首先keystone是在openstack的Essex版本正式推出的，一直沿用至今，基本的作用總結一句話就是：用於為其他組件提供統一認證服務，包含身份驗證、令牌發放和校驗、服務列表、用戶許可權定義等。

而在openstack整體架構中有很多關於keystone的基本概念，比如: User、Credentials、Authentication、Token、Tenant、Service、Endpoint、Role。

詳細內容，可以參考下面的思維導圖。

Keystone基本概念關鍵詞思維導圖

接下來舉一個創建虛擬機VM的例子，來簡單的認識一下keystone的大概流程，請看下圖。

keystone的workflow示意圖

1.User發送相關認證信息，一般是用戶名和密碼。

2.Keystone在自身的Mysql(默認情況會採用mysql進行用戶信息存儲)中查詢，發現含有正確的用戶名和密碼。則返回該對應用戶的憑證Token。

以上步驟如果是GUI操作，則為登錄成功後顯示到控制台界面了。

3.User發出創建VM虛擬機操作，在後台其實是將創建的請求+Token一起發送給Nova節點。

4.Nova在後台與Keystone溝通，一問Token是否正確，二問該Token是否有許可權創建VM。

5.以上如果驗證通過後，則Nova會與Glance通信，發出請求原VM鏡像請求，同樣在這個後台通信過程中，也是帶有Token通信的。

6.Glance發現Nova發出的調用鏡像請求後，則會從請求數據包中同時取到Token，這時會向keystone服務組件發去效驗，一問Token是否正確，二問是否有使用許可權。

7.確認沒問題後，Glance調取並推送鏡像給Nova，這時Nova可以根據原鏡像進行複製克隆創建出來一個新的*.qcow2鏡像給虛擬機使用。

8.下面Nova同樣需要給新的虛擬機配置一些網路周邊的信息，所以一樣將請求發送給Neutron。

9.Neutron拿到該請求後，則做同樣驗證操作，向Keystone溝通，一問Token憑證是否正確，二問Token是否有許可權創建網路相關內容。

10.經Keystone確認沒問題後，Neutron進行相關網路操作，而後向Nova服務組件上報操作完畢。想在這裡說一下的是，以上這部分操作全部是我們在控制台上，點擊確認提交創建要求後，後端自動發生的一系列行為，最終我們在前端這部分是看不到的。

11.Nova組件服務，在控制台GUI頁面顯示創建完成，至此用戶User可以得知虛擬機創建完成。這步是最後創建虛擬機完成後最終在控制台的GUI頁面上面表示出來的，也即為虛擬機成功創建完成。

在整體的Keystone流程中，很有可能出現的兩個Error錯誤:

keystone內部認證流程示意圖

1.如果User發出的請求Token在Keystone驗證無效後，則顯示401錯誤代碼。

2.如果Token有效，但是Keystone無法提供服務，則顯示503錯誤代碼。

總結一下:其實在openstack整體認證過程中，只要很好的理解Token憑證認證就很好的理解整體的3A控制了，簡單一句話就是KeyStone根據用戶提供的信息，返回Token憑證，以後在用戶任何的操作過程中，均有Token憑證代替傳統的Username/Password，以此來避免多次用戶敏感信息的交互，增加安全性。

同時Token的工作方式能夠很好的滿足openstack各個組件強關聯之間的認證和許可權控制，使得整體架構在用戶身份鑒別方面設計的不必過度複雜，使得整體架構更加」松耦合」。

再來看看實際應用，我們拿一些公有雲先來看看，下面是阿里雲和百度雲的截圖示例:

阿里雲AK/SK生成頁面

百度雲AK/SK生成頁面

我相信眾多的IT大佬們在玩公有雲的時候，多多少少會用到AK(Access Key)/SK(Secret Key)，類似上面的截圖，目前基本上公有雲廠商都應該具備，如果連這個都沒有，那可以認為這個公有雲做的真心一般還沒有能夠提供對外服務API介面的能力。

阿里雲API產品文檔

百度雲產品文檔(Endpoint地址)

百度雲產品文檔(API使用須知)

我們登錄到各個公有雲Console控制台後，創建的AK/SK其實就是手動生成Token憑證的過程，然後可以對接各個服務組件的API Web訪問的Endpoint地址就可以對接該平台的公有雲了，AK/SK實現用戶認證與許可權控制，Endpoint實現遠程後台接入，兩者疊加就可以操作雲平台了，我相信以後的混合雲也應該是走這個方式與各家的公有雲進行對接。

轉自「張家大公子」，內容略有改動。

熱文閱讀

溫馨提示：

Stay hungry,Stay foolish

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！