導讀：本博文簡要介紹openstack中keystone模塊，受衆是剛接觸openstack的同學。
- 什麼是keystone？
- 爲什麼要keystone?
- keystone爲什麼要設計成這樣？
- keystone client有哪些命令？
- keystone 工作流程？
爲了形象介紹keystone概念，我們假設OpenStack爲一家新成立的公司，其主要業務是對外提供服務，具體服務請自行腦補^^.
新公司剛開業，爲首之際當然是招聘員工。小型創業公司人手不要多，每個服務來一個就夠用。經過一番拼搏，最後脫穎而出的有nova，glance，neutron等。公司老闆想，人數不多嘛，大家互相見一見就認識了，不如就由nova負責他們的信息認證。
公司人手招夠，開始對外服務，作爲第一波顧客的我們來到OpenStack櫃檯。一看有客人到來，負責安全認證的nova趕緊上來問我們是誰，打哪而來，準備去哪。我們剛準備回答，glance樓上大喊一聲將nova叫走。老闆一看nova業務繁忙也確實忙不過來，是應該考慮再招一個人，這個人工作內容是什麼呢，老闆開始思考。無論如何，先招待第一波客人是關鍵，於是老闆親自來招待我們。首先當然是登記個人信息，註冊一個賬號。信息不用多，名字，密碼，郵箱即可。老闆想，最好是有這樣的一個表讓顧客申請，叫做user。
- admin 系統管理員
- test 普通User
- glance,nova OpenStack服務提供模塊
此表設計當真簡介明瞭，無差別對待員工和顧客，等等，這樣怎麼體現我們員工的優越性。得做點什麼區分一下我們的員工和顧客。爲了方便管理，最好有一張區別身份的表,就叫做tenant吧，nova啊,glance統統塞到service好了，留一個admin是我日後要找的管理員。
突然樓上nova電話打叫保安，好像是有一個顧客偷偷跑到他們後臺辦公地方。老闆一想nova可是公司核心員工，所做的都關乎公司核心機密，怎麼好讓顧客能讓公司裏隨便出入呢。一定要杜絕這個現象，要在顧客信息里加一欄權限。但是剛纔客戶表也填好了，也不好讓顧客重新填。那就乾脆重新弄一張表來記錄用戶的權限，就叫它role吧
每一個用戶可以分配不同的角色， 如這裏列出有member和admin。
老闆終於解決了用戶信息的問題，剛想坐下來喝杯茶休息一下，我們的glance又來了。glance問老闆，我找不到nova了，老闆想了下nova業務衆多，給他分配的辦公室也多，找起來是不方便。最好可以記錄下每個員工的位置信息，這樣新員工入職後，也方便老員工去找。最好是先記錄每個員工是幹什麼的，再記錄他們辦公在哪，而且這兩張表還要分開，因爲辦公室有可能更改。記錄員工工作內容的就叫 service，記錄員工工作地方的就叫endpoint好了。
這樣一來，終於解決了用戶信息，權限的問題，我們也方便去找哪個員工此時在哪。想到此時老闆就對要招的新員工的工作有個定位了，他就是管理所有人信息，記錄每個人的權限，記錄每個員工的職位，以及辦公地點。有了上述信息後，他就可以驗證每個顧客和員工的身份信息。恩，他就叫keystone.
keystone正式加入Openstack後，第一天上班老闆交給他一本崗位手冊，上面告知它的工作內容是什麼。首先他需要認證用戶的身份合法並且具有執行相應操作的權限，其次用戶在使用服務時，提供服務的人（比如nova）是其本人。最後Openstack各個組件間交互時，也要由他驗證身份和權限。除此之外還要維護下表列出的一些表單，主要操作是增刪改查。
| type | Description | Add | Delete | Update | Get |
|---|---|---|---|---|---|
| user | 用戶，理解爲公司內員工 | create | delete | update/password-update | list/get |
| tenant | 租戶，理解爲公司內不同的部門 | create | delete | update | list/get |
| role | 角色，理解爲公司部門內不同的權限 | create | delete | list/get | |
| service | 服務，用於註冊服務 | create | delete | list/get | |
| endpoint | 端點，用於記錄服務地址 | create | delete | list/get | |
| ec2-credentials | 信任證書 | create | delete | list/get | |
| user-role | 綁定用戶和權限的關係 | add | remove | update | list |
keystone工作一段時間後，發覺每次驗證用戶的賬號密碼，很是麻煩，效率太低，而且用戶等待時間也過久，嚴重印象了服務質量。於是他向老闆提出建議，能不能發一個token給驗證過的用戶，讓用戶在之後的一段時間裏可以使用token作爲身份信息，那這樣驗證起來效率就高很多。老闆一聽感覺還不錯，就答應了。於是就有了這樣的驗證機制：
- admin_token認證
- 用戶密碼方式認證
- 本地認證
- Token認證
- 外部認證
很快公司又出臺了keystone工作流程以爲提高keystone服務質量。
服務間訪問流程如下：
- 創建keystone client對象。通過keystone client向keystone服務器發送認證請求，申請用戶token。
- 創建要訪問的組件相應的client對象，根據對象找到其endpoint信息
- client向openstack服務發送http請求，通過auth_token過濾器認證。認證通過後，openstack調用相應的方法處理請求。
至此新員工keystone工作介紹就告一段落了。