自 2010 年末首次發(fā)布，OpenStack 已經(jīng)成為了使用最為廣泛的 Infrastructure as a Service (IaaS)云平臺(tái)之一。OpenStack 是一個(gè)不斷成長的開源解決方案套件，由核心項(xiàng)目和孵化項(xiàng)目組成。各個(gè)項(xiàng)目之間是松耦合的關(guān)系，通過 Message Queue 和 REST API 進(jìn)行通訊。考慮到性能等問題，OpenStack 官方默認(rèn)的配置都是非加密的。在一些企業(yè)級(jí)的應(yīng)用中，用戶對通訊的加密非?？粗?。本文簡單介紹如何通過配置，使 OpenStack 的 REST API 通訊以 SSL 加密方式進(jìn)行。

開始之前

環(huán)境準(zhǔn)備

• 一個(gè) RHEL 6.5 的 Linux 操作系統(tǒng)
• 運(yùn)行在 RHEL6.5 之上的 OpenStack Icehouse 版本

文中術(shù)語說明

• REST：含狀態(tài)傳輸（英文：Representational State Transfer，簡稱REST），是目前主流的 web 服務(wù)實(shí)現(xiàn)方案之一。它是一種設(shè)計(jì)風(fēng)格，以 URI 表示資源，并且支持資源的獲取、創(chuàng)建、修改和刪除。
• SSL：安全套接層（Secure Sockets Layer，SSL）是一種安全協(xié)議，目的是為互聯(lián)網(wǎng)通信，提供安全及數(shù)據(jù)完整性保障。

OpenStack 通訊機(jī)制概述

本文假設(shè)讀者已經(jīng)對 OpenStack 有了一定的了解，因此對 OpenStack 的發(fā)展及使用場景不再贅述。僅對與本文相關(guān)的通訊機(jī)制部分作一定的說明。

OpenStack 由多個(gè)相對獨(dú)立的項(xiàng)目組成，每個(gè)項(xiàng)目有獨(dú)立的代碼，并且能獨(dú)立運(yùn)行。項(xiàng)目與項(xiàng)目之間協(xié)同工作，完成了一個(gè)基礎(chǔ)架構(gòu)云平臺(tái)。由于各個(gè)項(xiàng)目獨(dú)立運(yùn)行，因此，相互之間的通訊顯得格外重要。OpenStack 的各個(gè)項(xiàng)目之間，有兩種通訊方式，一種是基于 AMQP（Advanced Message Queuing Protocol ）的消息隊(duì)列機(jī)制；一種是 REST 風(fēng)格的 HTTP 請求。在空閑時(shí)間，各個(gè)項(xiàng)目之間相安無事。一旦某個(gè)項(xiàng)目發(fā)生了變化，首先會(huì)通過消息隊(duì)列將變化傳遞到相關(guān)的項(xiàng)目，之后被通知的項(xiàng)目再通過 HTTP 請求來獲得變化的具體內(nèi)容。對于 OpenStack 中的某些較大項(xiàng)目，在項(xiàng)目內(nèi)部又細(xì)分成幾個(gè)模塊，這幾個(gè)模塊之間的通訊可能就是消息隊(duì)列和 HTTP 請求并存。

OpenStack 各個(gè)項(xiàng)目本身都支持 SSL 加密認(rèn)證。但是，如果對通訊都進(jìn)行 SSL 加密，耗時(shí)必然會(huì)加大。因此，出于性能考慮，OpenStack 的默認(rèn)配置都沒有使能 SSL。本文將簡要介紹如何將一個(gè)默認(rèn)的 OpenStack 云環(huán)境，配置成 REST API 是 SSL 加密的云環(huán)境。本文之后部分所描述的 SSL 加密都是針對 OpenStack 各個(gè)項(xiàng)目的 REST API，本文之后部分的通訊都是指各個(gè)項(xiàng)目之間的 HTTP 請求通訊。

#p#

以 SSL 方式配置 Keystone 的 REST API

Keystone（OpenStack Identity Service）在 OpenStack 框架中，負(fù)責(zé)身份驗(yàn)證和服務(wù)令牌等功能，它實(shí)現(xiàn)了 OpenStack 的 Identity API。Keystone 類似一個(gè)服務(wù)總線，或者說是整個(gè) OpenStack 框架的注冊表， 其他服務(wù)通過 Keystone 來注冊其服務(wù)的 Endpoint（服務(wù)訪問的 URL），任何服務(wù)之間相互的調(diào)用，首先需要經(jīng)過 Keystone 的身份驗(yàn)證，來獲得目標(biāo)服務(wù)的 endpoint 來找到目標(biāo)服務(wù)。有關(guān) Keystone 的更多信息，可以查看 Keystone 的 wiki。

因?yàn)?Keystone 會(huì)與所有其他的 OpenStack 項(xiàng)目通訊，先配置好 Keystone，可以在配置其他項(xiàng)目時(shí)把該項(xiàng)目與 Keystone 的通訊也配置成 SSL 加密方式。反之，如果先配置別的項(xiàng)目，在 Keystone 完成 SSL 配置之后，還需要再在各個(gè)項(xiàng)目中將 Keystone 部分的配置修改成 SSL 加密的方式。因此，本文首先對 Keystone 進(jìn)行配置。

生成自簽名證書

SSL 通訊的核心是基于證書的，Keystone 比較方便的是，能生成一個(gè)用于測試的自簽名證書。執(zhí)行以下命令：

# keystone-manage ssl_setup --keystone-user keystone --keystone-group keystone 

清單 1. 用 Keystone 命令生成用于測試的自簽名證書

執(zhí)行完清單 1 的命令后，在/etc/keystone/ssl 路徑下會(huì)新增幾個(gè)證書文件。為了確保 Keystone 能正常讀取文件，修改文件的用戶組。

清單 2. 修改 Keystone 生成的證書文件所在的用戶組

# chown -R keystone:keystone /etc/keystone/ssl 

修改 Keystone 的 endpoint

Endpoint 的概念在后面還會(huì)多次出現(xiàn)，這里簡單說一下。endpoint，翻譯為“端點(diǎn)”，我們可以理解它是一個(gè) OpenStack 項(xiàng)目暴露出來的訪問點(diǎn)，如果需要訪問一個(gè)項(xiàng)目，可以先獲取它的 endpoint，再從 endpoint 進(jìn)行訪問。OpenStack 中，endpoint 是由 Keystone 進(jìn)行管理的。這么做是合理的，因?yàn)?Keystone 與所有項(xiàng)目都進(jìn)行通訊。在 Keystone 中包含一個(gè) endpoint 模板，這個(gè)模板提供了所有存在的項(xiàng)目 endpoint 信息。一個(gè) endpoint template 包含一個(gè) URLs 列表，列表中的每個(gè) URL 都對應(yīng)一個(gè)項(xiàng)目實(shí)例的訪問地址，并且具有 public、internal 和 admin 這三種權(quán)限。public url 可以被全局訪問，internal url 只能被局域網(wǎng)訪問，admin url 被從常規(guī)的訪問中分離。

由于本文想將 Keystone 配置成 SSL 加密，因此需要讓所有的訪問者知道 Keystone 服務(wù)的入口已經(jīng)改變了，可以通過修改 Keystone 的 endpoint 來實(shí)現(xiàn)這一目的。

清單 3. 獲取當(dāng)前的 Keystone endpoint 列表

#keystone endpoint-list 

 通過讀取 Keystone 的配置文件可以知道它的 public 端口是 5000，internal 和 admin 端口是 35357。通過端口號(hào)能從 endpoint list 中找到 Keystone 的 endpoint。由于 Keystone 在 V2 版本不提供修改 endpoint 的接口，在這里可以先創(chuàng)建一個(gè)新的 https 的 endpoint，再刪除之前的 endpoint。

清單 4. 創(chuàng)建 Keystone 的 SSL endpoint

# keystone endpoint-create 
--service keystone --region RegionOne --publicurl 
https://{keystoneHost}:5000/v2.0 --internalurl 
https://{keystoneHost}:35357/v2.0 --adminurl 
https://{keystoneHost}:35357/v2.0 

清單 4 中的{keystoneHost}是指 Keystone 所在的 host。這里要注意，一定要先添加 HTTPS 的 endpoint，再刪除舊的 HTTP 的 endpoint。否則會(huì)由于找不到 Keystone 服務(wù)的入口導(dǎo)致后繼的操作將無法進(jìn)行。

添加完成之后，Keystone 相當(dāng)于有兩個(gè) endpoint 暴露出來了，在實(shí)際中究竟使用哪一個(gè)呢？答案是不確定。這就導(dǎo)致在添加完 HTTPS 的 endpoint 之后，Keystone 提供給自己的服務(wù)入口可能是 HTTPS 的，也可能是舊的 HTTP 的。在這里可以做個(gè)測試，執(zhí)行清單 3 的命令，如果命令不能返回 endpoint 列表，則說明 Keystone 對外暴露的是 HTTPS 的 endpoint。反之，則說明 Keystone 對外暴露的仍然是舊的 HTTP 的 endpoint，此時(shí)，可以刪除該 endpoint，以確保 Keystone 對外暴露的是 HTTPS 的 endpoint。

清單 5. 刪除 Keystone 的 http endpoint

# keystone 
endpoint-delete {old endpoint id} 

 清單 5 中，{old endpoint id}是通過清單 3 中的指令獲取的舊的 Keystone 的 endpoint 的 id。

此時(shí)，由于對外暴露的 Keystone 服務(wù)端口已經(jīng)是 SSL 的，但是其本身還是以非 SSL 方式運(yùn)行，所以 Keystone 服務(wù)已經(jīng)無法使用了。我們需要將 Keystone 本身也修改成以 SSL 加密認(rèn)證方式工作。

修改 Keystone 的 SSL 相關(guān)配置

由于已經(jīng)通過清單 1 的命令生成了用于測試的自簽名證書，在本小節(jié)需要將其寫入 Keystone 的配置。打開 Keystone 的配置文件，修改如下配置項(xiàng)：

清單 6. 修改 Keystone 的 SSL 相關(guān)配置

# vi 
/etc/keystone/keystone.conf [ssl] enable = True certfile = 
/etc/keystone/ssl/certs/keystone.pem keyfile = 
/etc/keystone/ssl/private/keystonekey.pem ca_certs = 
/etc/keystone/ssl/certs/ca.pem 

 為了使修改的配置生效，重啟 Keystone 服務(wù)。

清單 7. 重啟 Keystone 服務(wù)

# service openstack-keystone restart 

 至此，Keystone 的 SSL 配置已經(jīng)完成了，Keystone 對外的接口已經(jīng)是 SSL 加密認(rèn)證的，所有訪問的 url 都是 HTTPS 開頭的。為了使之后的命令能執(zhí)行，需要更新 OpenStack cli 的認(rèn)證 url。

清單 8. 更新 OpenStack cli 的認(rèn)證 url

# export 
OS_AUTH_URL=https://{keystoneHost}:5000/v2.0 

 如果之前沒有做，現(xiàn)在可以刪除之前的舊的 http 的 endpoint。

清單 9. 刪除 Keystone 的非 SSL endpoint

# keystone –-insecure 
endpoint-delete {old endpoint id} 

 清單 9 中，{old endpoint id}是通過清單 3 中的指令獲取的舊的 Keystone 的 endpoint 的 id。

這里說明一下清單 9 中的參數(shù) --insecure。 OpenStack 的 CLI 命令，實(shí)際上都是通過執(zhí)行 curl 命令調(diào)用相應(yīng)項(xiàng)目的 REST API 來實(shí)現(xiàn)。我們之前是用一個(gè)自簽名的證書來配置 Keystone 的 SSL 加密認(rèn)證，這個(gè)證書是不被 curl 所認(rèn)可的。加上 --insecure 參數(shù)可以讓 curl 忽略這個(gè)證書。另一方面，也可以將這個(gè)自簽名證書導(dǎo)入 curl，具體操作見參考資源，這樣就可以省去該參數(shù)。如果是通過別的工具，例如 Firefox 來訪問 OpenStack 的 REST API，僅需要在第一次訪問時(shí)接受證書，之后就可以正常訪問了。

#p#

以 SSL 方式配置 Nova 的 REST API

Nova（OpenStack Compute Service）在 OpenStack 框架中，負(fù)責(zé)虛機(jī)的管理，是整個(gè) Infrastructure as a Service 系統(tǒng)中的最重要部分。有關(guān) Nova 的更多信息，可以查看 Nova 的 wiki。但是在 SSL 配置中，Nova 的地位與其他項(xiàng)目一樣。因此，本文將不會(huì)逐個(gè)介紹如何對各個(gè)項(xiàng)目進(jìn)行 SSL 配置，僅以 Nova 為例說明。
配置 Nova 以 SSL 加密方式連接 Keystone

前面已經(jīng)將 Keystone 配置成 SSL 加密認(rèn)證了。由于 OpenStack 所有的其他項(xiàng)目都需要通過 Keystone 進(jìn)行用戶認(rèn)證，而默認(rèn)的配置，都是以非 SSL 方式連接 Keystone。所以，理論上此時(shí)除了 Keystone，OpenStack 的其他項(xiàng)目都已經(jīng)無法使用了。所以，配置 Nova 的第一步，應(yīng)將 Nova 中有關(guān) Keystone 的部分修改成 SSL 加密的。

清單 10. 修改 Nova 配置以 SSL 方式連接 Keystone

# vi 
/etc/nova/API-paste.ini auth_uri = https://10.1.0.92:5000/v2.0 
auth_protocol = https insecure = True 

這里的 insecure = True 與之前說明的 --insecure 參數(shù)是一個(gè)道理。 修改完之后，重啟 nova-API，以使配置生效。

清單 11. 重啟 nova-API

# service openstack-nova-API restart 

 此時(shí)，Nova 已經(jīng)可以使用了?？梢允褂靡韵旅顧z驗(yàn)之。

清單 12. 查看 nova 下所有 hypervisor

# nova --insecure hypervisor-list 

 在檢驗(yàn)時(shí)需要注意，由于 Nova 可能與其他項(xiàng)目也存在交互，例如調(diào)用 Nova 的某些命令，可能需要去 Neutron 取數(shù)據(jù)，而 Neutron 同樣也需要經(jīng)過 Keystone 認(rèn)證。但是，在目前的步驟，Neutron 還沒有被配置，所以，Neutron 中有關(guān) Keystone 的配置仍然是非 SSL 的。這個(gè)時(shí)候 Neutron 的是無法通過 Keystone 認(rèn)證的，數(shù)據(jù)也無法獲取，最終會(huì)導(dǎo)致 Nova 的相應(yīng)命令執(zhí)行失敗。因此，在目前的步驟下，檢驗(yàn) Nova 需要用一些只使用 Nova 內(nèi)部數(shù)據(jù)的命令，例如清單 12。

生成自簽名證書

Nova 不像 Keystone，提供命令生成用于測試的自簽名證書。我們在這里使用前面 Keystone 的證書。首先將證書拷貝至 Nova 目錄下，然后修改證書所在的用戶組以供 Nova 使用。

清單 13. 將 Keystone 的證書拷貝至 Nova 目錄下

# mkdir /etc/nova/ssl # cp 
/etc/keystone/ssl/certs/keystone.pem /etc/nova/ssl/ # cp 
/etc/keystone/ssl/private/keystonekey.pem /etc/nova/ssl/ # chown -R 
nova:nova /etc/nova/ssl/ 

修改 Nova 的 endpoint

endpoint 的概念之前已經(jīng)介紹過了，這里直接調(diào)用清單 3 中的命令，獲取 endpoint 列表。從 Nova 的配置文件中可以知道它的 public，internal 和 admin 端口是 8774。

清單 14. 創(chuàng)建 Nova 的 SSL endpoint

# keystone --insecure 
endpoint-create --service nova --region RegionOne --publicurl 
"https://{novaHost}:8774/v2/%(tenant_id)s" --internalurl 
"https://{novaHost}:8774/v2/%(tenant_id)s" --adminurl 
"https://{novaHost}:8774/v2/%(tenant_id)s" 

創(chuàng)建完成之后，刪除之前的非 SSL endpoint 以避免混淆。相應(yīng)的命令參見清單 9。此時(shí)，由于對外暴露的 Nova 服務(wù)端口已經(jīng)是 SSL 的，但是其本身還是非 SSL 方式運(yùn)行，所以 Nova 服務(wù)又無法使用了。我們需要將 Nova 本身也修改成以 SSL 加密認(rèn)證方式工作。

修改 Nova 的 SSL 相關(guān)配置

直接修改 Nova 的配置文件，

清單 15. 修改 Nova 的 SSL 相關(guān)配置

# vi /etc/nova/nova.conf [DEFAULT] 
enabled_ssl_APIs=osAPI_compute 
ssl_cert_file=/etc/nova/ssl/keystone.pem 
ssl_key_file=/etc/nova/ssl/keystonekey.pem 

修改完配置之后，調(diào)用清單 11 的命令重啟 nova-API 以使配置生效。之后用清單 12 中的命令測試結(jié)果即可。如果想看具體的調(diào)用，可以加上 --debug 參數(shù)?？梢园l(fā)現(xiàn)，現(xiàn)在所有的 curl 命令都調(diào)用 https 的 url。

總結(jié)

OpenStack 在 Icehouse 版本共有 9 個(gè)核心項(xiàng)目，若干個(gè)孵化項(xiàng)目。隨著 OpenStack 的成長，項(xiàng)目數(shù)還會(huì)增加。出于性能考慮，OpenStack 所有的項(xiàng)目默認(rèn)都是以非 SSL 方式工作，需要用戶手動(dòng)修改配置以使能 SSL。在修改配置上，Keystone 由于其在整個(gè)架構(gòu)中所處的特殊地位，而略有不同。其他的項(xiàng)目，如 Glance、Cinder、Neutron 等，雖然在配置文件中某些屬性可能不同，但是配置過程與 Nova 大致相同。讀者可以嘗試按照 Nova 的配置過程去配置其他的項(xiàng)目。