В интерфейсах пользователя и документации OpenStack, группа пользователей называется проектами или владельцами (tenant). Эти термины взаимозаменяемые.

Первоначальная реализация вычислительной службы (Compute Service) OpenStack (nova) имела собственную систему аутентификации и использовался термин проект. После перемещения аутентификации в проект службы идентификации (Identity Service) OpenStack (keystone), для названия группы пользователей используется термин владелец (tenant). Из-за такого наследия некоторые инструменты OpenStack используют термин проекты, а некоторые термин владельцы.

	Совет
	Данное руководство использует термин проект, , за исключением примера, демонстрирующего взаимодействие с инструментом, который использует термин владелец.

Пользователи должны быть связаны хотя бы с одним проектом, хотя они и могут принадлежать множеству проектов. Следовательно, перед добавлением пользователей вы должны создать хотя бы один проект.

 Добавление проектов

Чтобы создать проект при помощи инструментальной панели OpenStack:

1. Войдите в систему с правами администратора.

2. Выберите закладку Admin в левой панели навигации.

3. Под панелью идентификации (Identity Panel), кликните на Projects.

4. Кликните по кнопке Create Project (создать проект).

Вам будет предложено ввести название проекта и, что не является обязательным, однако рекомендуется, его описание. Чтобы включить этот проект, установите флажок в нижней части формы. По умолчанию эта опция включена, как показано на Рисунке 9.1., “Форма создания проекта в инструментальной панели”.

 

Рисунок 9.1. Форма создания проекта в инструментальной панели

Источник рисунка

Кроме того, можно добавить участников проекта и скорректировать его квоты. Мы обсудим это позже, однако, на практике может оказаться весьма удобным иметь дело со всеми этими операциями одновременно.

Для добавления проекта с использованием командной строки необходимо применить утилиту keystone, которая использует термин To add a project through the command line, you must use the keystone utility, which uses владелец (tenant) вместо проект:

# keystone tenant-create --name=demo

Данная команда создает проект с именем "demo". По желанию вы можете добавить строку описания путем добавления --description tenant-description, что может быть очень полезным. Также вы можете создать группу в отключенном состоянии путем добавления в команде --enabled false. По умолчанию проекты создаются во включенном состоянии.

Для предотвращения исчерпания системных возможностей без предупреждения можно настроить квоты. Квоты являются эксплутационными пределами. Например, можно управлять количеством доступных владельцу гигабайт, чтобы пребывать в уверенности, что отдельный владелец не займет все доступное дисковое пространство. В настоящее время квоты применяются на уровне владельца (или проекта), а не на уровне пользователя.

	Предостережение
	Поскольку без разумного квотирования отдельный владелец может использовать все доступные ресурсы, OpenStack поставляется с квотами по умолчанию. Вы должны обратить внимание на то, какие установки квот имеют смысл для имеющегося у вас оборудования.

Используя интерфейс командной строки, вы можете управлять квотами служб вычислительной среды и блочных хранилищ OpenStack.

Как правило, значения по умолчанию изменяются, поскольку владельцу требуется больше, чем установленное в OpenStack по умолчанию значение 10 томов на владельца, или более чем установленное по умолчанию в OpenStack значение в 1Тб дискового пространства на вычислительном узле.

Замечание

Для просмотра всех владельцев выполните команду: $ keystone tenant-list +---------------------------------+----------+---------+ | id | name | enabled | +---------------------------------+----------+---------+ | a981642d22c94e159a4a6540f70f9f8 | admin | True | | 934b662357674c7b9f5e4ec6ded4d0e | tenant01 | True | | 7bc1dbfd7d284ec4a856ea1eb82dca8 | tenant02 | True | | 9c554aaef7804ba49e1b21cbd97d218 | services | True | +---------------------------------+----------+---------+

 Квотирование образов

OpenStack Havana ввела базовую функцию квотирования для служб образов, так что теперь вы можете ограничивать хранение образов проекта общим числом байт. В настоящее время эта квота применяется по всему облаку, так что если вы установите предел квотирования в 5ГБ, то все проекты в вашем облаке будут в состоянии хранить только 5ГБ образов и моментальных снимков.

Для включения этой функции, отредактируйте файл /etc/glance/glance-api.conf, и в разделе [DEFAULT] добавьте:

user_storage_quota = <bytes>

Например, чтобы ограничить хранение образов проектов 5ГБ, сделайте так:

user_storage_quota = 5368709120

	Замечание
	В редакции Icehouse, существует опция настройки в glance-api.conf, которая ограничивает число участников, которым разрешен доступ к образу, называемое image_member_quota, по умолчанию установленное в значение 128. Эта настройка является квотой, отличающейся от квоты хранения.

[pipeline:main]
pipeline = healthcheck [...] container_quotas account_quotas proxy-server

[filter:account_quotas]
use = egg:swift#account_quotas

[filter:container_quotas]
use = egg:swift#container_quotas
   

$ swift stat

   Account: AUTH_b36ed2d326034beba0a9dd1fb19b70f9
Containers: 0
   Objects: 0
     Bytes: 0
Meta Quota-Bytes: 214748364800
X-Timestamp: 1351050521.29419
Content-Type: text/plain; charset=utf-8
Accept-Ranges: bytes

$ swift post -m quota-bytes:
     <bytes>

$ swift post -m quota-bytes:
     5368709120

$ swift stat

   Account: AUTH_b36ed2d326034beba0a9dd1fb19b70f9
Containers: 0
   Objects: 0
     Bytes: 0
Meta Quota-Bytes: 5368709120
X-Timestamp: 1351541410.38328
Content-Type: text/plain; charset=utf-8
Accept-Ranges: bytes

Инструменты командной строки для управления пользователями неудобны для непосредственного использования. Они требуют выдачи нескольких команд для выполнения одной задачи, а также для многих элементов они используют UUID вместо символических имен. На практике люди, как правило, не используют эти инструменты непосредственно. К счастью, инструментальная панель OpenStack (Dashboard) обеспечивает приемлемый интерфейс для этих целей. Кроме того, многие сайты написали пользовательские инструменты для собственных потребностей по обеспечению соблюдения локальных политик и обеспечивают уровни самообслуживания для пользователей, которые не доступны в настоящее время в виде пакетов инструментов.

Для создания пользователя вам потребуется следующая информация:

Имя пользователя и адрес электронной почты не требуют пояснений, хотя ваш сайт может иметь локальные соглашения, которые вы должны соблюдать. Установка и изменение паролей в службе идентификации (Identity Service) требует административных привилегий. Начиная с версии Folsom пользователи не могут изменять свои собственные пароли. Это является большим стимулом для создания локальных пользовательских инструментов, и должно приниматься во внимание при назначении и распространении паролей. Первичный проект просто является первым ассоциированным с пользователем проектом и он должен существовать перед созданием пользователя. Роль почти всегда устанавливается в значение "участник". Распространяемый в дистрибутиве OpenStack поставляется с двумя ролями, определяемыми как:

Можно определять и другие роли, но это не является общей практикой.

После того, как вы собрали эту информацию, создание пользователя в инструментальной панели Dashboard является просто заполнением еще одной веб-формы, подобной тем, которые мы видели ранее, и которую можно найти по ссылке Users (Пользователи) в панели навигации Admin, с последующим нажатием кнопки Create User (Создать пользователя) в правом верхнем углу.

Изменение пользователей выполняется также на данной странице Пользователи (User). Если у вас имеется большое количество пользователей, то эта страница может стать довольно переполненной. Поле поиска Filter (Фильтр) в верхней части страницы можно использовать для ограничения просматриваемых пользователей. Очень похожая на диалог создания пользователя форма может быть раскрыта выбором Edit (редактирование) в действиях ниспадающего меню в конце линии для изменяемого пользователя.

Многие сайты работают с пользователями, ассоциируемыми только с одним проектом. Это является более традиционным и простым выбором как для администрирования, так и для пользователей. С точки зрения администрирования: если пользователь сообщает о проблеме с экземпляром или квотой, то очевидно, о каком проекте идет речь. Пользователям не следует беспокоиться о том, в рамках какого проекта они работают, если они участвуют только в одном проекте. Тем не менее, обратите внимание, что по умолчанию любой пользователь может повлиять на ресурсы и любого другого пользователь в рамках своего проекта. Кроме того, можно ассоциировать пользователей с несколькими проектами, если это имеет смысл для вашей организации.

Связывание существующих пользователей с дополнительным проектом или их удаление из старого проекта выполняется на странице Projects (Проекты) в инструментальной панели Dashboard, при выборе Modify Users (Изменить пользователей) в колонке Actions (Действия), как показано на Рисунок 9.2, “Вкладка редактирования участников проекта”.

В данном представлении вы можете выполнить ряд полезных, впрочем, также и опасных вещей.

Первый столбец в данной форме, озаглавленный All Users (Все пользователи), включает в себя список всех пользователей вашего облака, которые пока не ассоциированы с данным проектом, а во втором пользователи, которые уже связаны с ним. Они могут быть достаточно длинными, однако их можно ограничить набором подстроки имени пользователя, которого вы ищете в поле фильтрации в верхней части столбца.

В данном месте нажмите иконку + для добавления пользователя к проекту. Кликните на - для его удаления.

 

Рисунок 9.2. Вкладка редактирования участников проекта

Источник рисунка

Вероятность угрозы происходит из возможности изменения ролей участников. А именно, после имени пользователя в списке Project Members (Участники проекта) существует ниспадающий список. Почти всегда его значение должно быть установлено в Member (Участник). Данный пример намеренно демонстрирует и пользователя с правами администратора, где это значение установлено admin (Администратор).

	Предостережение
	Администратор (admin ) является глобальным, не только для определенного проекта, следовательно предоставление этой роли в любом проекте дает пользователю права администратора во всем облаке.

Обычная практика заключается в создании только одного пользователя с правами администратора в отдельном проекте, по договоренности, это обычно проект admin, создаваемый по умолчанию при установке облака. Если ваши пользователи с правами администратора также используют облако для запуска и управления экземплярами, настоятельно рекомендуется использовать отдельные учетные записи для административного доступа и для обычной работы, а также их принадлежность различным проектам.

{
        "context_is_admin":  [["role:admin"]],
        "admin_or_owner":  [["is_admin:True"], \
        ["project_id:%(project_id)s"]],  
        "default": [["rule:admin_or_owner"]],  
        "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:migrate": [["rule:admin_api"]],
        "compute_extension:aggregates": [["rule:admin_api"]],
        "compute_extension:certificates": [ ],
        ...
        "compute_extension:flavorextraspecs": [ ],
        "compute_extension:flavormanage": [["rule:admin_api"]],  
        }
        

"compute_extension:flavormanage": [ ],

Одним из ключевых элементов системного администрирования, который часто упускается из виду, заключается в том, что конечные пользователи являются причиной, объясняющей наличие системных администраторов. Не следуйте маршрутом BOFH и не прерывайте каждого пользователя, который вызывает сигнал отключения. Поработайте с ними, чтобы понять, что они пытаются сделать, и увидеть, как ваша среда может лучше помочь им в достижении их целей. Удовлетворите потребности ваших пользователей путем организации ваших пользователей в проекты, применения политик, управления квотами и работая с ними.