一個OpenStack云沒有用戶的話，它并沒有多大的價值。在本文中，將介紹如何管理用戶、項目和配額。

項目或租戶？

在OpenStack用戶界面和一些文檔中，有時候你會看到“項目”是指一組用戶，而有時候你會也看到用來替代“租戶”，這兩種術語是可以通用的。

這背后的歷史原因是因為最初OpenStack計算服務(nova)有著自己的身份驗證系統，并使用的術語“項目”。當認證系統獨立成為OpenStack身份識別服務(Keystone)項目后，新項目中使用的術語“租戶”代指一個用戶組。由于這一問題，一些OpenStack工具是指“項目”，有些是指“租戶”。

在本手冊中，我們將采用術語“項目”，除非我們在一些示例工具中使用術語“租戶”。

管理項目

一個用戶必須至少屬于一個項目，也可以屬于多個項目。因此,您應該至少添加一個項目，然后再添加用戶。

添加項目

通過儀表盤來創建一個項目：

1. 用管理員用戶登錄。
2. 在左側導航欄中選擇“項目”按鈕。
3. 在右上角，點擊“創建項目”按鈕。

這將會彈出一個對話框，有項目名稱和一個可選的描述，在底部有一個復選框來設置這個項目的狀態，默認是開啟的.

 

從上面可以看到，也可以添加項目成員和調整項目的配額。我們在討論過這些后在做修改，當然你也可以一次性處理完上面的操作。

通過命令行創建一個項目(CLI)：

通過命令行添加一個項目，你需要使用keystone工具，使用”租戶”代替”項目”：

# keystone tenant-create --name=demo 

這將創建一個新項目命名為“demo”。可以用 –description <tenant-description> 參數添加一些描述，這是非常有用的。也可以用 –enable false 參數創建一個禁用狀態的租戶，不指定是默認開啟狀態。

配額

OpenStack提供了大量配額選項，并都是針對租戶的配額(而不是用戶)。作為一個管理用戶在儀表盤中你可以看到(但不能編輯)一個”配額”導航欄的默認配額。這些默認項目配額都是在云控制器上 nova.conf 里默認的。

如果你不更改配額限制，系統會使用以下默認配額。

nova.conf文件里配額配置選項的描述

選項默認值	(類型) 描述
quota_cores=20	(IntOpt) 允許租戶使用的CPU核數
quota_floating_ips=10	(IntOpt) 允許租戶使用的浮動IP數
quota_gigabytes=1000	(IntOpt) 設置租戶的網絡帶寬
quota_injected_file_content_bytes=10240	(IntOpt) 允許注入文件的字節數
quota_injected_file_path_bytes=255	(IntOpt) 允許注入文件路徑的字節數
quota_injected_files=5	(IntOpt) 允許注入文件的數量
quota_instances=10	(IntOpt) 允許租戶創建實例的數量
quota_key_pairs=100	(IntOpt) 允許每個用戶的密鑰對數量
quota_metadata_items=128	(IntOpt) 允許每個實例的元數據項數量
quota_ram=51200	(IntOpt) 允許租戶使用的內存大小
quota_security_group_rules=20	(IntOpt) 每個安全組中規則的數量
quota_security_groups=10	(IntOpt) 每個租戶創建安全組的數量
quota_volumes=10	(IntOpt) 每個租戶使用邏輯卷的數量

其它配置選項(http://docs.openstack.org/folsom/openstack-compute/admin/content/list-of-compute-config-options.html)

最簡單的方式來改變默認的項目配額就是在你的云控制器上編輯 nova.conf 文件。配額是由 nova-schedler 服務執行，所以你一旦改變默認配額選項，你必須重新啟動該服務。

通過儀表盤來查看和編輯個別項目的配額：

1. 使用“項目”導航按鈕鏈接獲得到您現有項目的列表。
2. 找到要修改的項目并從下拉菜單中選擇“Modify Quotas”，修改相應的配額，最后點擊“Save”完成修改。

通過命令行方式查看和編輯個別項目的配額，請按照下列步驟操作：你可以在命令行方式訪問和修改配額，但這有點復雜。這是通過使用 keystone 來獲取租戶的ID，然后再用 nova-manage 查看。

1. 要列出一個項目的配額，必須要先使用 keystone 客戶端工具找到它的ID:

# keystone tenant-list | grep <tenant-name> 

98333a1a28e746fa8c629c83a818ad57 | <tenant-name> | True |

2. 回想一下，keystone 客戶端工具使用“租戶”， nova 客戶端工具使用“項目”為同一個概念。為了查看項目的配額，我們必須使用上面例子中獲取的ID:98333a1a28e746fa8c629c83a818ad57:

# nova-manage project quota 98333a1a28e746fa8c629c83a818ad57 

metadata_items: 128 volumes: 10 gigabytes: 1000 ram: 6291456 security_group_rules: 20 instances: 1024 security_groups: 10 injected_file_content_bytes: 10240 floating_ips: 10 injected_files: 5 cores: 2048

注意：nova-manage project quota 后面必須指定ID，輸入項目名稱會報錯。

現在給 floating_ips 數量提高至20，我們可以用 –key 和 –value 來增加 ip 數：

# nova-manage project quota 98333a1a28e746fa8c629c83a818ad57 --key floating_ips --value 20 

metadata_items: 128 volumes: 10 gigabytes: 1000 ram: 6291456 security_group_rules: 20 instances: 1024 security_groups: 10 injected_file_content_bytes: 10240 floating_ips: 20 injected_files: 5 cores: 2048

用戶管理

在命令行用戶管理用戶非常不方便。需要多條命令才能完成一個任務，并且要是用UUID，而不是象征性的名字。在實踐中，人們通常不會使用命令行管理用戶。幸運的是，OpenStack 儀表盤提供了一個合理的接口。此外，許多網站編寫的自定義腳本也可能會適合您。

創建用戶

要創建一個新的用戶，您將需要以下信息：

• 用戶名
• 郵箱
• 密碼
• 所屬主要項目
• 角色

用戶名和電子郵件都是不言而喻的，雖然你的網站可能有本地習慣，但是這樣便于觀察。設置和更改密碼的認證服務，需要管理員權限。在 Folsom 版本中，用戶不能更改自己的密碼。創建完用戶和密碼后，必須牢記分配的用戶名和密碼。項目必須在個創建用戶之前存在。角色就是一個”會員”，可以直接使用：

• “member”: 一個典型的用戶。
• “admin”: 超級管理員用戶，在所有項目中，你應該謹慎使用它。

它可以定義其它角色，但很少這樣做。

一旦你收集了這些信息，創建用戶只是在儀表盤上的一個web表單形式，類似我們所見過的，可以發現”用戶”鏈接在“Admin”導航欄上，然后點擊右上角“創建用戶”按鈕。

修改用戶也從“Users”的頁面。如果你有大量的用戶，這個頁面會很擁擠。在頁面的頂部有”Filter”可以用來搜索相關用戶列表，與創建用戶對話框相似，可以通過”Edit”或下拉菜單中的動作來修改用戶信息。

關聯用戶到項目

許多網站運行與用戶相關的只有一個項目。這是一種較為保守和簡單的管理用戶選擇。在管理上，一個用戶報告出現很明顯問題的一個實例或配額，如果它們在一個項目中，用戶不必擔心它們的行為是哪個項目。然而，需要注意在默認情況下，任何用戶都可以影響到這個項目下其他用戶資源的使用額度。也可以讓用戶關聯多個項目，這樣的組織比較有意義。

在儀表盤“項目”頁面可以關聯現有的用戶到一個額外的項目或刪除它們從一個舊的項目，通過選擇”項目”頁面的指示板“修改用戶”：

在這個視圖中，你可以做許多有用和危險的事情。

在標題為“All Users”表格中，將會列出這個項目所有的用戶。用戶過多，顯示可能會很長，在頂部有過濾器可以限制輸入用戶名來搜索。

在這里,點擊”+”將添加一個用戶到項目,然后點擊“-“將刪除它們。

這里存在危險性，就是可能會改變成員的角色.在“Project Members”列表中的用戶名后面的下拉列表中,一般情況下，這個值應該被設置為“Member”，這個例子意在說明，管理員用戶這個值是“admin”。 它是非常重要的，“admin”是全局用戶，而不是每個項目，因此授予用戶admin角色時候就等于賦予該用戶在任何項目里管理整個云的權利。

按照慣例，典型的應用是在一個單一的項目里，該項目創建默認設置云管理用戶。如果您的管理用戶使用云資源來啟動和管理，強烈建議您使用單獨的用戶賬戶來管理訪問權限和云正常運作，它們在不同的項目里。

自定義授權

缺省的授權設置只允許管理用戶創建代表不用的項目資源.OpenStack處理兩種類型的授權策略：

1. 操作為主：操作指定訪問特定的操作標準,可能于特定屬性的控制權。
2. 資源型：對特定資源的訪問是否可能授權或根據配置的資源（目前僅適用于網絡資源）的權限。從部署到實際OpenStack的服務執行不同的授權策略部署。

策略引擎讀取policy.json文件的條目。這個文件的實際位置可能會有所不同，它通常是在/etc/nova/policy.json.在系統運行時，您可以更新條目,而不必重新啟動服務。目前更新這些的唯一方法就是編輯策略文件。

OpenStack的服務的策略引擎直接匹配策略，一個規則表明了這些策略的元素。例如，在一個compute:create:[[“rule:admin_or_owner”]]聲明，這項策略是compute:create并且規則是admin_or_owner。

策略是來誘發OpenStack策略引擎只要其中一個匹配一個API操作或特定OpenStack屬性被使用給一個特定的操作。例如，在實例上，compute:create:策略用戶每次發送一個POST /v2/{tenant_id}服務請求到OpenStack Compute API服務器。策略也可以與特定的API進行擴展。例如，如果一個用戶需要一個compute_extension:rescue屬性由提供程序定義的擴展屬性觸發操作規則測試。

一個授權策略可以由一個或多個規則組成。如果有多個規則指定，評估政策是否成功在于任何規則評估成功，如果一個API操作匹配多個策略，然后所有的策略必須評估成功。同時，授權規則是遞歸的。一旦一個規則匹配，規則(s)可以決定另一個規則，直到達到最后一個規則。這些定義的規則：

1. 基于角色的規則：成功提交請求的用戶具有指定的角色。比如管理員提交一個實例“role:admin”是成功的。
2. 字段規則：如果字段指定的資源在當前請求匹配一個特定的值就評估成功。例如“field:networks:shared=True”屬性共享的網絡資源被設置為True。
3. 通用規則：比較屬性與用戶的安全憑據中提取的一種屬性的資源和評估成果比較成功的。比如“tenant_id:%(tenant_id)s”是成功的，如果租戶標識符在資源里等于租戶標識用戶提交請求。

以下是nova里一段默認policy.json文件的內容：

{ “context_is_admin”: [[“role:admin”]], “admin_or_owner”: [[“is_admin:True”], [“project_id:%(project_id)s”]], [1] “default”: [[“rule:admin_or_owner”]], [2] “compute:create”: [], “compute:create:attach_network”: [], “compute:create:attach_volume”: [], “compute:get_all”: [], “admin_api”: [[“is_admin:True”]], “compute_extension:accounts”: [[“rule:admin_api”]], “compute_extension:admin_actions”: [[“rule:admin_api”]], “compute_extension:admin_actions:pause”: [[“rule:admin_or_owner”]], “compute_extension:admin_actions:unpause”: [[“rule:admin_or_owner”]], “compute_extension:admin_actions:suspend”: [[“rule:admin_or_owner”]], “compute_extension:admin_actions:resume”: [[“rule:admin_or_owner”]], ... “compute_extension:admin_actions:migrate”: [[“rule:admin_api”]], “compute_extension:aggregates”: [[“rule:admin_api”]], “compute_extension:certificates”: [], “compute_extension:cloudpipe”: [[“rule:admin_api”]], ... “compute_extension:flavorextraspecs”: [], “compute_extension:flavormanage”: [[“rule:admin_api”]], [3] }

[1] 成功的計算規則，如果當前用戶是管理員或所有者的請求中指定的資源（承租人標識符相等）。

[2] 顯示默認的策略，始終是評估API操作不匹配的策略的policy.json。

[3] 顯示一個策略，限制管理員使用管理API的能力。

在某些情況下,某些操作應限制只有管理員才能執行。因此，作為進一步的例子，讓我們考慮何樣的策略文件進行修改的情況下，我們可以讓用戶創建自己的策略配置： “compute_extension:flavormanage”: [],

有問題的用戶(某個用戶干擾了其它用戶)

在很多情況下，當用戶在你的云中會破壞其他用戶，有時故意和惡意，其它可能會意外。了解情況，可以讓你做出更好的決定如何處理。

例如：A組的用戶有非常計算密集型任務的情況下，利用大量的計算資源。這時負載的計算節點上，會影響其他用戶。在這種情況下，請查看您的用戶使用的情況。對這種情況，高密度計算方案是常見的，可以把您的云主機聚合或應適當的規劃隔離。

另一個例子是一個用戶消耗了非常大的帶寬量。再次，關鍵是要了解用戶在做什么。如果他們自然是需要大量的帶寬，您可能需要限制其傳輸速率，以不影響其他用戶或將它們移動到一個區域更多的可用帶寬里。另一方面，也許用戶的實例被黑客入侵，并發動DDOS攻擊的成為僵尸網絡的一部分。這個問題的解決方案是一樣的，如果網絡上的任何其他的服務器已經被黑客入侵。聯系用戶，使他們有時間作出反應。如果他們不回應，關閉實例。

最后一個例子是，如果一個用戶反復使用云資源。聯系用戶，并了解他們正在嘗試做的。也許他們不明白他們在做什么是不適當的或可能有問題的資源，他們正在試圖訪問，是造成他們請求隊列或滯后的。

系統管理常常被忽視的一個關鍵因素是，最終用戶是系統管理員存在的原因。要了解用戶他們所要做的事情，看看您的環境可以更好地幫助他們實現自己的目標。