С 1991 года на компьютерном рынке России

т.: 676 0965, 676 0396
Москва, Сосинская ул. 43,
м. Волгоградский проспект

ГЛАВА 9

Управление проектами и пользователями

Пользуйтесь переводом существенно переработанной и дополенной 2й редакции (12-дек-2014),
находящейся теперь и в режиме постоянно обновляемой документации
(последняя пока доступна только на англ.яз.).

Без пользователей облако OpenStack не имеет большого значения. В данной главе рассматриваются темы, связанные с пользователями, проектами и квотами.

Проекты или владельцы

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

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

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

Управление проектами

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

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

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

Войдите в систему с правами администратора.
Выберите ссылку "Projects" (Проекты) в левой панели навигации.
Справа вверху кликните на кнопку "Create Project" (Создать проект).

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

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

Чтобы создать проект с использованием интерфейса командной строки (CLI):

Для добавления проекта с использованием командной строки необходимо применить утилиту keystone, которая использует термин "владелец" (tenant) вместо "проект" (project).
# keystone tenant-create --name=demo

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

Квоты

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

Используя интерфейс командной строки вы можете управлять квотами OpenStack Compute Service и Block Storage Service.

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

Установка квот вычислительной службы (Compute Service)

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

Fixed Ips
Количество фиксированных IP- адресов, доступных владельцу. Это число должно быть больше или равно числу доступных экземпляров.
Fixed Ips

Floating Ips
Количество плавающих IP, доступных владельцу
floating-ips

Injected File Content Bytes
Количество байт содержимого, доступных для внедряемого файла
injected-file-content-bytes

Injected File Path Bytes
Количество байт, доступных для пути внедряемого файла
injected-file-path-bytes

Injected Files
Количество внедряемых файлов, доступных владельцу
injected-files

Instances
Количество экземпляров, доступных владельцу
instances

Key Pairs
Количество ключевых пар, доступных пользователю
key-pairs

Metadata Items
Количество элементов метаданных, доступных экземпляру
metadata-items

Ram
Объем ОЗУ в мегебайтах, доступных владельцу
ram

Security Group Rules
Количество правил, доступных группе безопасности
security-group-rules

Security Groups
Количество групп безопасности, доступных владельцу
security-groups

VCPUs
Количество ядер экземпляров, доступных владельцу
cores

Просмотр и обновление вычислительных квот для владельца (проекта)

Для просмотра и обновления квот владельца вы можете использовать поддерживаемые клиентом python-novaclient команды nova quota-* в качестве пользователя с правами администратора.

Для просмотра и обновления значения квот по умолчанию

Выведите список всех квот по умолчаниюдля всех владельцев следующим образом:
$ nova quota-defaults
Например:
$ nova quota-defaults +-----------------------------+-------+ | Property | Value | +-----------------------------+-------+ | metadata_items | 128 | | injected_file_content_bytes | 10240 | | ram | 51200 | | floating_ips | 10 | | key_pairs | 100 | | instances | 10 | | security_group_rules | 20 | | injected_files | 5 | | cores | 20 | | fixed_ips | -1 | | injected_file_path_bytes | 255 | | security_groups | 10 | +-----------------------------+-------+
Обновите значения по умолчанию для нового владельца следующим образом:
$ nova quota-class-update default key value
Например:
$ nova quota-class-update default instances 15

Чтобы просмотреть значения квот для владельца (проекта)

Поместите ID владельца в используемую переменную следующим образом:
$ tenant=$(keystone tenant-list | awk '/tenantName/ {print $2}')
Выведите список значений квот, установленных в настоящее время для владельца следующим образом:
$ nova quota-show --tenant $tenant
Например:
$ nova quota-show --tenant $tenant +-----------------------------+-------+ | Property | Value | +-----------------------------+-------+ | metadata_items | 128 | | injected_file_content_bytes | 10240 | | ram | 51200 | | floating_ips | 12 | | key_pairs | 100 | | instances | 10 | | security_group_rules | 20 | | injected_files | 5 | | cores | 20 | | fixed_ips | -1 | | injected_file_path_bytes | 255 | | security_groups | 10 | +-----------------------------+-------+

Чтобы обновить значения квот для владельца (проекта)

Поместите ID владельца в используемую переменную следующим образом:
$ tenant=$(keystone tenant-list | awk '/tenantName/ {print $2}')
Обновите определенное значение квоты следующим образом:
# nova quota-update --quotaName quotaValue tenantID
Например:
# nova quota-update --floating-ips 20 $tenant # nova quota-show --tenant $tenant +-----------------------------+-------+ | Property | Value | +-----------------------------+-------+ | metadata_items | 128 | | injected_file_content_bytes | 10240 | | ram | 51200 | | floating_ips | 20 | | key_pairs | 100 | | instances | 10 | | security_group_rules | 20 | | injected_files | 5 | | cores | 20 | | fixed_ips | -1 | | injected_file_path_bytes | 255 | | security_groups | 10 | +-----------------------------+-------+
Для просмотра списка опций команд обновления квот выполните:
$ nova help quota-update

Установка квот блочного хранилища (Block Storage)

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

gigabytes
Объем доступных на томе данных в гигабайтах, доступных для каждого владельца.

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

volumes
Количество томов блочного хранилища, доступных каждому владельцу.

Просмотр и обновление квот блочного хранилища для владельца (проекта)

Для просмотра и обновления квот владельца вы можете использовать поддерживаемые пакетом python-cinderclient команды cinder quota-* в качестве пользователя с правами администратора.

Для просмотра и обновления значения квот блочного хранилища по умолчанию

Выведите список всех квот по умолчанию для всех владельцев следующим образом:
$ cinder quota-defaults
Например:
$ cinder quota-defaults +-----------+-------+ | Property | Value | +-----------+-------+ | gigabytes | 1000 | | snapshots | 10 | | volumes | 10 | +-----------+-------+
Чтобы обновить значение по умолчанию для нового владельца, обновите атрибут в файле /etc/cinder/cinder.conf.

Чтобы просмотреть квоты блочного хранилища для владельца (проекта)

Выведите список всех квот по умолчанию для всех владельцев следующим образом:
# cinder quota-show tenantName
Например:
# cinder quota-show tenant01 +-----------+-------+ | Property | Value | +-----------+-------+ | gigabytes | 1000 | | snapshots | 10 | | volumes | 10 | +-----------+-------+

Для обновления квот блочного хранилища

Прим. перев.: в оригинале допущена опечатка, а именно: данный раздел называется "To update Compute service quotas" вместо "To update Block Storage service quotas".

Поместите ID владельца в используемую переменную следующим образом:
$ tenant=$(keystone tenant-list | awk '/tenantName/ {print $2}')
Обновите определенное значение квоты следующим образом:
# cinder quota-update --quotaName NewValue tenantID
Например:
# cinder quota-update --volumes 15 $tenant # cinder quota-show tenant01 +-----------+-------+ | Property | Value | +-----------+-------+ | gigabytes | 1000 | | snapshots | 10 | | volumes | 15 | +-----------+-------+

Управление пользователями

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

Создание нового пользователя

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

Имя пользователя
Адрес электронной почты
Пароль
Первичный проект
Роль

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

"участник" (member): типичный пользователь.
"администратор" (admin): административный супер пользователь, наделенный полные правами для всех проектов, который должен использоваться с большой осторожностью.

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

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

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

Связывание пользователей с проектами

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

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

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

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

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

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

Значение "admin" является глобальным не только для одного проекта, следовательно предоставляет пользователю роль администратора в любом проекте, давая права администратора во всем облаке.

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

Настройка авторизации

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

На основе операций: политики описывают критерии доступа для определенных операций, возможно с уточняющим управлением с использованием конкретных атрибутов.
На основе ресурсов: в соответствии с разрешениями, определяемыми для ресурса, определяется: может или нет предоставляться определенный ресурс (на время написания [переводимой книги] доступно только для сетевого ресурса). Фактические политики, вводимые в действие службой OpenStack изменяются от развертывания к развертыванию.

Механизм политик читает записи из файла policy.json. Фактическое местонахождение этого файла может варьироваться от дистрибутива к дистрибутиву, для nova это обычно /etc/nova/policy.json. Вы можете обновлять записи во время работы системы, при этом вы не должны перезапускать службы. В настоящее время единственный способ обновлять такие политики заключается в редактировании файла политик.

Механизм службы политик OpenStack помечает политику непосредственно. Например, в операторе compute:create:[["rule:admin_or_owner"]], политикой является compute:create, а правило - admin_or_owner.

Политики включаются механизмом политик OpenStack всякий раз, когда одна из них соответствует операции OpenStack API или для данной операции используется конкретный атрибут. Например, механизм проверяет политику create:compute всякий раз, когда пользователь отправляет запрос POST /v2/{tenant_id}/servers серверу OpenStack Compute API. Политики также могут быть связаны с определенными расширениями API. Например, если пользователю необходимо расширение подобное compute_extension:rescue, атрибуты, определенные поддержкой расширений включают проверку правила для этой операции.

Политики авторизации могут состоять из одного или большего количества правил. Если задано много правил, политика оценивается как успешная когда выполняется одно из правил; если операция API помечает много политик, то все политики должны определиться успешными. Помимо этого, правила авторизации рекурсивны. После того, как правило совпало, оно (они) могут быть приняты для решения другого правила, пока не будет достигнуто завершающее правило. Существуют определенные правила:

Правила, определяемые ролями (Role-based): оцениваются успешным в случае, когда выполняющий запрос пользователя имеет описываемую роль. Например, "role:admin" является успешным, если выполняющий запрос пользователь является администратором.
Правила, определяемые полями (Field-based): оцениваются как успешные, если поле описываемого ресурса в текущем запросе соответствует определенному значению. Например, "field:networks:shared=True" является успешным, если атрибут сети совместной используемости (shared) имеет значение истинно (True).
Общие правила (Generic): сравнивает атрибут в ресурсе с атрибутом, извлекаемым из учетных данных пользователя и принимается успешным, при успешном сравнении. Например, "tenant_id:%(tenant_id)s" является успешным, если идентификатор владельца в ресурсе равен идентификатору владельца для выполняющего запрос пользователя.

Вот фрагменты файла policy.json nova по умолчанию:
{ "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:migrate": [["rule:admin_api"]], "compute_extension:aggregates": [["rule:admin_api"]], "compute_extension:certificates": [ ], ... "compute_extension:flavorextraspecs": [ ], "compute_extension:flavormanage": [["rule:admin_api"]], [3] }

[1] Демонстрирует правило, которое оценивается как успешное, если текущий пользователь является администратором или владельцем указанного в ресурсе запроса (равным идентификатору владельца)

[2] Демонстрирует политику по умолчанию, принимаемую всегда, когда операция API не соответствует ни одной из политик в policy.json

[3] Демонстрирует политику, ограничивающую возможность манипулирования предпочтениями (flavors) администраторами исключительно административными API.

В определенных случаях некоторые операции должны быть ограничены только для администраторов. Поэтому, в качестве еще одного примера, рассмотрим, как этот пример файла политики может быть изменен в сценарии, при котором мы позволим пользователям создавать свои собственные особенности (flavors):
"compute_extension: flavormanage": [],

Пользователи, разрушающие других пользователей

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

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

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

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

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

Глава 8	Оглавление	Глава 10

Перевод: Copyright © 2014 . All rights reserved. Ссылки обязательны (Refs and links obligatory).		http://www.mdl.ru