OpenStack之Keystone學習

   OpenStack 管理了衆多的軟硬件資源，而且利用這些資源提供雲服務。而任何資源的管理，都會涉及到安全的管理，具體分爲：

        用戶認證

        服務認證

        口令認證

   不管是私有云仍是共有云，都會開放許多的接口給衆多的用戶，而Keystone是OpneStone的安全組件，Keystone在對於用戶進行認證的同時，也對用戶的權限進行了限制。Keystone還保證OpenStack的服務能夠正常註冊。此外，各個服務組件之間的消息傳遞還須要用口令，當口令過時，則再也不使用此口令。

Domain至關於Keystone中的第一行政劃分，好比顯示世界中的國家

經過上圖咱們能夠看到，Users,，Groups，Projects都是劃分到了Domain中，即一個Domain會有各類各樣的Users，Groups，Projects；可是咱們會發現，Roles在不一樣的Domain中是惟一的，且不屬於Domain.

在Keystone中，Users/Projects/Groups都是按照Domain劃分的。Role是全局的，即一個用戶在Domain A中是admin,那麼在Domain B中會也是admin

Projects/Tenant（這兩個是）是OpenStack中的一組資源打包以後的抽象，好比VMS ,p_w_picpaths，Volumes等。意味着，這些資源都是歸這個Project/Tenant所擁有

Projects並不擁有users/users Groups(用戶/用戶組），users和users groups是利用role與Tenant產生聯繫的（稱爲Grant）

注：Projects和Tenant實際上是等價的概念，只是由於歷史緣由，名稱不一樣罷了，如今通常都用Tenant

Roles

users必須依靠某個Tenant才能夠進入keystone的世界，而users與Tenant的橋樑就是Roles

如：在家裏，role=(兒子/父親/母親），在學校，roles=（教師/學生/職工）

而一個users要和Tenant取得聯繫，就必須被賦予某個角色，如userA 經過Admin角色進入Tenant,userB經過member角色進入到Tenant

問：有時候並不清楚一個user應該被加到那個Tenant中，則此時用戶如何直接與Keystone進行認證？

答：建立與用戶名同名的Tenant,以下圖

在爲users綁定一個簡單的角色（role），如Admin，在綁定這個Admin給與users同名的Tenant，這樣用戶即可以直接與keystone進行交互

注：在建立Tenant時，咱們能夠故意將其建立的和用戶名稱同樣，這是一中取巧的方法

問：Tenant的做用是什麼？

如王二這個users本身確定是王二組的admin,但王二也有可能被分配到開發組，且在開發組是一個member，這樣王二就能夠利用member這個role進入到開發組，從而使用開發組的資源，可是他的權限在開發組中是受到限制的

鄭五既是本身組的Admin有是開發組的Admin，便可以利用Admin這個role進入到開發組，並使用開發組的全部資源，而且擁有全部權限

王二和鄭五的區別就是對於開發組的role不一樣，則這兩我的對開發組的虛擬機資源的使用權限也就不一樣

Tenant做用的另外一個場景

Keystone會建立一個叫作service的Tenant，而後經過service這個Tenant把OpenStack的全部其餘服務都註冊到這個叫service的Tenant上面，如將Neutron，Nova，Galance等service服務所有註冊進入service這個Tenant中，從而對服務進行統一的管理

問：Domain的做用是什麼？

Domain主要是進行域的劃分

若有兩個域，一個爲亞太研發區，一個爲歐洲研發區

而在亞太研發區中，有2個Tenant，分別爲研發組和測試組；三個users，分別爲，研發經理，測試經理Peter，且Peter只是研發組和測試組這兩個Tenant的member（role 爲member）

經過這種行政劃分，咱們即可以把不一樣的Domain，不一樣的Tenant，不一樣的users進行相應的綁定

問：如何區別不一樣Domain中同名的Tenant或users？

答：經過UUID來區分

在openstack/keystone中都是經過UUID進行區分的，全部的名稱都是給人看的，對Keystone來講，全部的的資源都是經過UUID區分的。

如在亞太研發區和歐洲研發區中都有Peter這個users這個用戶存在，單對openstack來講這是兩個用戶，只是名稱相同罷了，他們的UUID是不一樣的，同理研發組這個Tenant在兩個域中也是不一樣的，其UUID也不一樣

若UUID相等，則說明是指同一個資源，UUID是openstack中的×××，能夠將Keystone比做公安局，現實中的公安局也是經過×××進行區分人的，而openstack中全部的資源，全部的內部識別都是經過UUID進行的區分

keystone 的認證哲學：

1: 咱們都是本身的Admin，因此通常建立Tenant時會建立一個與本身同名的Tenant

2: users進入不一樣的Tenant時必須標識本身的角色是什麼（Admin，member）

3: 若是不在某個Tenant中，則對這個Tenant中資源是不可見的；由於角色不一樣，Tenant中的資源權限也不相同

keystone中的認證流程：

即：須要進入keystone中通常要提供：密碼，用戶名，Domain名，Tenant。

問：是否是每次的認證都要提供用戶名和密碼？

答：並非，第一次認證須要提供用戶名，密碼，Tenant，Domain，而後keystone會返回一個Token給用戶使用，之後每次都依靠keystone發送的Token進行認證

經過這個Token，能夠查到這個用戶的密碼/用戶名/權限/屬於哪一個Tenant等信息

下面是一個用戶建立虛擬機的流程

1：用戶發送證書就是提供了用戶名/密碼/Tenant/Domain

2：keystone返回一個令牌，令牌就是Token

3：用戶提供建立的請求+Token給Nova組件

4：Nova收到用戶提供的請求和Token後，會詢問keystone，用戶提供的Token是否合法？用戶是否能使用這個服務？若果keystone驗證沒有問題，則進入第五步

5：Nova提交常見鏡像的請求+Token給Glance，Glance收到Nova提供的請求和Token，會繼續詢問Token，這個Token是否合法，用戶是否可使用此服務？若是keystone驗證經過，則一直往下走

。。。。。。。

。。。。。

能夠看到openstack中，後面的全部服務都是採用Token進行認證的，因此用戶沒必要每次都輸入用戶名/密碼

問：keystone如何知道其餘的服務在哪裏？怎麼知道其餘的服務請求是否合法？

答：這是就要用到catalog

keystone除了負責用戶的認證以外，還負責Service Endpoint的管理。這個功能相似於現實 中的工商局，市場全部提供的服務都要在工商局進行註冊備案

在返回用戶的Token時，keystone也會返回全部在keystone上祖冊的服務列表

以下圖：

1：用戶提供用戶名，密碼，Domain，Tenant

2：keystone返回Token + 各類已經註冊的服務的地址

3：用戶拿到Token +Nova的服務地址，則向Nova發起請求

4：Nova拿到用戶提供的Token，而後詢問keystone，Token是否合法 +用戶是否有權限使用服務。。。。。。。

Policy
Policy主要用來判斷一個用戶是否是Admin，是否是一個資源的owner等；Policy可讓Roles這個這個角色正真的產生做用，即真正區分一個users能幹什麼？不能幹什麼？

Policy在當前仍是靜態的，如判斷一我的是否是Admin，是經過policy.json裏面的定義進行的，接着經過「role==admin」......等判斷

下圖爲policy.json文件

keystone服務和特色：

identify：存儲了用戶，能夠提供用戶相應的認證

Assignment：存儲了權限的管理

Resource：存儲了Tenant，Domain等

Token：用來解決用戶後續的認證（保證沒必要每次認證都須要輸入用戶名和密碼）

Catalog：存儲了全部已經在keystone上註冊過的服務信息和地址

Policy：真正實現Roles的做用，區分一個Users的權限

注：本文不涉及Keystone的安裝操做

keystone安裝完成以後，keystone還不能直接使用，還必須進行keystone的初始化。

1：向Catalog中註冊keystone服務

2：keystone註冊Admin用戶

3：keystone建立service Tenant

4：keystone穿件Demo用戶