Без кейворда

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

Хотя версия 3 API идентификации уже доступна, инструменты клиентов пока еще не поддерживают эти вызовы, и большинство облаков OpenStack все еще реализуют API идентификации v2.0.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Квоты

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

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

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

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

Для просмотра всех владельцев выполните команду:

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

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

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

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

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

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

Количество плавающих IP, доступных владельцу.

Injected file content bytes

Количество байт содержимого, доступных для внедряемого файла.

Injected file path bytes

Количество байт, доступных для пути внедряемого файла.

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

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

Количество ключевых пар, доступных пользователю.

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

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

Security group rules

Количество правил, доступных группе безопасности.

Количество групп безопасности, доступных владельцу.

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

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

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

Выведите список всех квот по умолчаниюдля всех владельцев следующим образом:

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

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

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

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

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

Пoлучите ID владельца следующим образом:

Обновите определенное значение квоты следующим образом:

Для просмотра списка опций команды quota-update выполните:

Квотирование хранилищ объектов было введено вSwift 1.8 (OpenStack Grizzly). В настоящее время существует две категории квот для хранилищ объектов:

Ограничивают общий объем (в байтах) или число объектов, которое может быть сохранено в одном контейнере.

Квоты учетных записей

Ограничивает общий размер (в байтах), который доступен пользователю в службе хранилища объектов.

Для того, чтобы воспользоваться либо квотами контейнера, либо квотами учетных записей, ваш сервер прокси хранилища объектов должен иметь container_quotas или account_quotas (или и то, и другое) добавленные в конвейер [pipeline:main] . Каждый тип квоты также требует свой собственный раздел в файле proxy-server.conf :

Для просмотра и обновления квот хранилища объектов воспользуйтесь командой swift , поддерживаемой пакетом python-swiftclient . Любой включенный в проект пользователь может просматривать размещенные в этом проекте квоты. Для обновления квот хранилища объектов в проекте вы должны иметь роль ResellerAdmin в том проекте, к которому применяются квоты.

Для просмотра размещенных в проекте квот учетных записей:

Для применения или обновления квот в проекте:

Например, для размещения квоты 5ГБ в учетных записях:

Для проверки квот снова выполните команду swift stat :

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

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

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

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

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

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

Выведите список всех квот по умолчанию для всех владельцев следующим образом:

Для обновления значений по умолчанию для новых владельцев, обновите атрибуты в файле /etc/cinder/cinder.conf .

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

Просмотрите квоты для владельцев следующим образом:

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

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

Обновите определенное значение квоты следующим образом:

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

Инструменты командной строки для управления пользователями неудобны для непосредственного использования. Они требуют выдачи нескольких команд для выполнения одной задачи, а также для многих элементов они используют 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, создаваемый по умолчанию при установке облака. Если ваши пользователи с правами администратора также используют облако для запуска и управления экземплярами, настоятельно рекомендуется использовать отдельные учетные записи для административного доступа и для обычной работы, а также их принадлежность различным проектам.

Параметры авторизации по умолчанию позволяют создавать ресурсы от имени другого проекта только пользователям с правами администратора. 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//servers серверу OpenStack Compute API. Политики также могут быть связаны с определенными расширениями API. Например, если пользователю необходимо расширение подобное compute_extension:rescue , атрибуты, определенные поддержкой расширений включают проверку правила для этой операции.

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

Оцениваются успешным в случае, когда выполняющий запрос пользователя имеет описываемую роль. Например, "role:admin" является успешным, если выполняющий запрос пользователь является администратором.

Правила, определяемые полями (Field-based rules)

Оцениваются как успешные, если поле описываемого ресурса в текущем запросе соответствует определенному значению. Например, "field:networks:shared=True" является успешным, если атрибут сети совместного использования (shared) имеет значение истинно ( true ).

Общие правила (Generic rules)

Сравнивает атрибут в ресурсе с атрибутом, извлекаемым из учетных данных пользователя и принимается успешным, при успешном сравнении. Например, "tenant_id:%(tenant_id)s" является успешным, если идентификатор владельца в ресурсе равен идентификатору владельца для выполняющего запрос пользователя.

Вот фрагменты файла policy.json nova по умолчанию:

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

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

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

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

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

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

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

Резюме

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