今天，我們深入到每一個服務元件詳細的來說說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實現遠端後臺接入，兩者疊加就可以操作雲平臺了，我相信以後的混合雲也應該是走這個方式與各家的公有云進行對接。

      轉自“張家大公子”，內容略有改動。

熱文閱讀

溫馨提示：

請搜尋“ICT_Architect”或“掃一掃”二維碼關注公眾號，點選原文連結獲取更多技術資料。

Stay hungry, Stay foolish