Управление политикой Keystone¶

Включение драйверов для файлов конфигурации домена¶

Чтобы включить драйверы для конкретного домена, установите следующие параметры в файле /etc/keystone/keystone.conf:

[identity]
domain_specific_drivers_enabled = True
domain_config_dir = /etc/keystone/domains

Когда вы включаете специфичные для домена драйверы, служба Identity ищет в каталоге domain_config_dir файлы конфигурации с именами keystone.DOMAIN_NAME.conf. Домен без специфичного для домена файла конфигурации использует параметры в основном файле конфигурации.

Включение драйверов для хранения параметров конфигурации в базе данных SQL¶

Чтобы включить драйверы для конкретного домена, установите следующие параметры в файле /etc/keystone/keystone.conf:

[identity]
domain_specific_drivers_enabled = True
domain_configurations_from_database = True

Любые специфичные для домена параметры конфигурации, указанные через Identity v3 API, переопределяют файлы конфигурации для конкретного домена в каталоге /etc/keystone/domains.

В отличие от файлового метода указания конфигураций для конкретного домена, параметры, заданные через Identity API, станут активными без необходимости перезапуска сервера Keystone. Из соображений производительности текущее состояние параметров конфигурации для домена кэшируется на сервере Keystone, а в многопроцессорных и многопоточных конфигурациях Keystone новые параметры конфигурации могут не стать активными, пока не истечет время кэширования. Параметры кэша для параметров конфигурации домена можно настроить в общем файле конфигурации Keystone (параметр cache_time в группе domain_config).

Важно отметить, что при использовании любого из этих методов указания параметров конфигурации, специфичных для домена, основной файл конфигурации Keystone по-прежнему сохраняется. Только те параметры, которые относятся к драйверу Identity для пользователей и групп (т. е. указывают, является ли драйвер для этого домена SQL или LDAP, и, если LDAP, параметры, определяющие это соединение), поддерживаются специфичным для домена способом. Кроме того, при использовании параметров конфигурации через Identity API параметр драйвера должен быть установлен на драйвер LDAP (попытка установить его на драйвер SQL вызовет ошибку при его последующем использовании).

Для существующих установок, которые уже используют файловые конфигурации для конкретных доменов, которые хотят перейти на подход на основе SQL, можно использовать команду keystone-manage для загрузки всех файлов конфигурации в базу данных SQL:

$ keystone-manage domain_config_upload --all

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

$ keystone-manage domain_config_upload --domain-name DOMAINA

Из-за того, что идентификаторы пользователей и групп должны быть уникальными для всей установки OpenStack, а Keystone может определить, какой домен и серверную часть (бэкенд) следует использовать, только по идентификатору пользователя или группы, он динамически создает постоянную таблицу сопоставления идентификаторов на основе общедоступного идентификатора к фактическому домену, локальному идентификатору (внутри этого бэкенда) и типу объекта. Публичный идентификатор автоматически генерируется Keystone при первом обнаружении сущности. Если локальный идентификатор объекта получен от бэкенда, который не гарантирует создание UUID, алгоритм хэширования сгенерирует общедоступный идентификатор для этого объекта, который будет раскрыт Keystone.

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

В то время как Keystone будет динамически поддерживать сопоставление удостоверений, включая удаление записей, когда объекты удаляются через Keystone, для тех объектов в бэкендах, которые управляются вне Keystone (например, LDAP только для чтения), Keystone не будет знать, были ли объекты удалены и следовательно, он будет продолжать содержать устаревшие сопоставления идентификаторов в своей таблице. Несмотря на то, что это безвредно, Keystone дает возможность операторам очищать таблицу сопоставления от таких устаревших записей с помощью команды keystone-manage, например:

$ keystone-manage mapping_purge --domain-name DOMAINA --local-id abc@de.com

Обычно оператор получает список тех записей во внешнем бэкенде, которые были внеполосно удалены в Keystone, а затем вызывает keystone-manage для очистки этих записей, указав домен и локальный идентификатор. Тип объекта (т. е. пользователь или группа) также может быть указан, если это необходимо для уникальной идентификации отображения.

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

$ keystone-manage mapping_purge --domain-name DOMAINA

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

$ keystone-manage mapping_purge --all

Генерация общедоступных идентификаторов при первом запуске может занять некоторое время, и, скорее всего, первые запросы API для получения списка пользователей завершатся ошибкой по тайм-ауту. Чтобы этого не произошло, необходимо выполнить команду mapping_populate. Она должна выполняться сразу после настройки LDAP или после map_purge:

$ keystone-manage mapping_populate --domain DOMAINA

Генераторы общедоступных идентификаторов¶

Keystone поддерживает настраиваемый генератор общедоступных идентификаторов, указанный в разделе [identity_mapping] файла конфигурации. Keystone по умолчанию предоставляет генератор sha256, который создает регенерируемые общедоступные идентификаторы. Алгоритм генератора общедоступных идентификаторов - это компромисс между размером ключа (т. е. длиной общедоступного идентификатора), вероятностью коллизии и, в некоторых случаях, безопасностью общедоступного идентификатора. Максимальная длина общедоступного идентификатора, поддерживаемая Keystone, составляет 64 символа, и генератор по умолчанию (sha256) полностью использует их. Поскольку общедоступный идентификатор — это то, что Keystone отдает во внешний мир, и потенциально он может храниться во внешних системах, некоторые установки могут захотеть использовать другие алгоритмы генератора, которые имеют другой компромисс атрибутов. Другой генератор можно установить, настроив следующее свойство:

• generator - генератор сопоставления идентификаторов. По умолчанию используется sha256 (реализовано keystone.identity.id_generators.sha256.Generator)

Перенос файлов конфигурации домена в базу данных SQL¶

Вы можете использовать команду keystone-manage для переноса параметров конфигурации из файлов конфигурации домена в базу данных SQL:

# keystone-manage domain_config_upload --all

Чтобы загрузить параметры из определенного файла конфигурации домена, укажите имя домена:

# keystone-manage domain_config_upload --domain-name DOMAIN_NAME

Настройка сервера Identity LDAP¶

# setsebool -P authlogin_nsswitch_use_ldap on

Конфигурация Identity разделена на две отдельные серверные части (бэкенда): идентификация identity (бэкенд для пользователей и групп) и назначения assignment (бэкенд для доменов, проектов, ролей, назначений ролей). Чтобы настроить удостоверение, задайте параметры в файле /etc/keystone/keystone.conf. С примерами конфигурации серверной части Identity можно ознакомиться в разделе Интеграция серверной части Identity с LDAP. Измените эти примеры по мере необходимости.

[ldap]
url = ldap://localhost
user = dc=Manager,dc=example,dc=org
password = samplepassword
suffix = dc=example,dc=org

url = "ldap://localhost,ldap://backup.localhost"

Интеграция серверной части Identity с LDAP¶

Серверная часть Identity содержит информацию о пользователях, группах и списках участников групп. Интеграция серверной части (бэкенда) Identity с LDAP позволяет администраторам использовать пользователей и группы в LDAP.

Защита подключения службы идентификации OpenStack к серверной части LDAP¶

Мы рекомендуем защищать все соединения между OpenStack Identity и LDAP. Служба идентификации поддерживает использование TLS для шифрования трафика LDAP. Прежде чем настраивать это, вы должны сначала проверить, где находится ваш файл центра сертификации. Дополнительные сведения в руководстве по безопасности OpenStack, ведение в протокол SSL.

После проверки местоположения файла центра сертификации:

# openstack-config --set /etc/keystone/keystone.conf \
  ldap use_tls True
# openstack-config --set /etc/keystone/keystone.conf \
  ldap tls_cacertfile ``CA_FILE``
# openstack-config --set /etc/keystone/keystone.conf \
  ldap tls_req_cert ``CERT_BEHAVIOR``

Кэширование токенов и проверка токенов¶

Подсистема токенов является наиболее часто используемым API OpenStack Identity. В результате все типы токенов выигрывают от кэширования, включая токены Fernet. Хотя токены Fernet не нужно сохранять, их все же следует кэшировать для оптимальной производительности проверки токена.

Система токенов имеет отдельный параметр конфигурации cache_time, для которого можно установить значение выше или ниже глобального значения expire_time по умолчанию, что обеспечивает поведение кэширования, отличное от других систем в OpenStack Identity. Этот параметр задается в разделе [token] файла конфигурации.

Время кэширования списка отзыва токенов определяется параметром конфигурации revocation_cache_time в разделе [token]. Список отзыва обновляется каждый раз, когда токен отзывается. Как правило, он получает значительно больше запросов, чем запросы на извлечение конкретных токенов или вызовы проверки токенов.

Вот список действий, на которые влияет кэшированное время:

• получение нового токена;
• отзыв токенов;
• проверка токенов;
• проверка токенов v3.

Вызовы API удаления токенов делают недействительным кэш для обрабатываемых токенов, а также делают недействительным кэш для списка отозванных токенов и вызовов проверки/проверки токенов.

Кэширование токенов настраивается независимо от кэширования revocation_list. Отменены проверки истечения срока действия от драйверов токенов к менеджеру токенов. Это гарантирует, что кэшированные токены по-прежнему будут поднимать флаг TokenNotFound по истечении срока действия.

Для согласованности кэша все идентификаторы токенов преобразуются в короткий хэш токена на уровне поставщика и драйвера токена. Некоторые методы имеют доступ к полному идентификатору (токенам PKI), а некоторые — нет. Аннулирование кэша несовместимо без нормализации идентификатора токена.

Кэширование для ресурсов, не являющихся токенами¶

Различные другие компоненты keystone имеют отдельный параметр конфигурации cache_time, который может быть установлен на значение выше или ниже глобального значения expiration_time по умолчанию, что позволяет использовать поведение кэширования, отличное от других систем в службе идентификации. Этот параметр можно задать в различных разделах конфигурационного файла (например, [role] и [resource]).

Действия по созданию, обновлению и удалению для доменов, проектов и ролей будут корректно аннулировать методы кэшированияы, перечисленные выше.

С дополнительными сведениями о различных серверных частях (и параметрах конфигурации) можно ознакомиться в следующих статьях:

• dogpile.cache.memory

• dogpile.cache.memcached

  Примечание

  Серверная часть (бэкенд) памяти не подходит для использования в производственной среде.

• dogpile.cache.redis

• dogpile.cache.dbm

Недействительность кэша¶

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

Пример настройки серверной части (бэкенда) memcached¶

В следующем примере показано, как настроить серверную часть memcached:

[cache]

enabled = true
backend = dogpile.cache.memcached
backend_argument = url:127.0.0.1:11211

Вам нужно указать URL-адрес для доступа к экземпляру memcached с параметром backend_argument.

Подробное ведение журнала кэша¶

Мы не рекомендуем использовать подробное ведение журнала кэша по умолчанию в производственных системах. Однако вам может потребоваться подробный журнал для устранения проблем с кэшем. Один из способов увидеть, как Keystone взаимодействует с серверной частью кэша — улучшить ведение журнала. Следующая конфигурация объединяет журналы oslo и dogpile в файл журнала keystone с повышенной детализацией:

[DEFAULT]
default_log_levels = oslo.cache=DEBUG,dogpile.core.dogpile=DEBUG

[cache]
debug_cache_backend = True

Эти журналы будут включать пробы и ошибки кэша, что упрощает диагностику конфигурации кэша и проблем с подключением.

Установка порога блокировки учетной записи¶

Функция блокировки учетной записи ограничивает количество попыток неправильного ввода пароля. Если пользователю не удается пройти аутентификацию после максимального количества попыток, служба отключает пользователя. Пользователей можно повторно включить, явно задав атрибут пользователя enable с помощью API-вызова update user v3.

Вы устанавливаете максимальное количество неудачных попыток аутентификации, устанавливая lockout_failure_attempts:

[security_compliance]
lockout_failure_attempts = 6

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

[security_compliance]
lockout_duration = 1800

Если вы не установите параметр lockout_duration, пользователи будут заблокированы на неопределенный срок, пока пользователь не будет явно включен через API.

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

Отключение неактивных пользователей¶

PCI-DSS 8.1.4 требует, чтобы неактивные учетные записи пользователей были удалены или отключены в течение 90 дней. Вы можете добиться этого, установив параметр disable_user_account_days_inactive:

[security_compliance]
disable_user_account_days_inactive = 90

Приведенный выше пример означает, что пользователи, не прошедшие аутентификацию (неактивные) в течение последних 90 дней, автоматически отключаются. Пользователей можно повторно активировать, явно установив атрибут enable user через API.

Принудительная смена пароля при первом использовании¶

PCI-DSS 8.2.6 требует, чтобы пользователи изменили свой пароль при первом использовании и после административного сброса пароля. В рамках API-интерфейса Identity создание пользователя и обновление пользователя считаются изменением пароля администратора. Принимая во внимание, что смена пароля для пользователя — это самостоятельная смена пароля. После включения этой функции новые пользователи и пользователи, у которых был сброшен пароль, должны будут изменить свой пароль при следующей аутентификации (первом использовании), прежде чем они смогут получить доступ к каким-либо службам.

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

Когда все будет готово, вы можете настроить его так, чтобы пользователи были вынуждены менять свой пароль при первом использовании, установив параметр change_password_upon_first_use:

[security_compliance]
change_password_upon_first_use = True

Настройка срока действия пароля¶

Срок действия паролей можно настроить на истечение определенного количества дней, установив параметр password_expires_days:

[security_compliance]
password_expires_days = 90

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

Если существует пользователь, для которого вы не хотите устанавливать срок действия пароля, Keystone поддерживает настройку этого параметра с помощью параметра пользователя ignore_password_expiry.

Настройка требований к надежности пароля¶

Вы можете установить требования к надежности пароля, такие как требование цифр в пароле или установка минимальной длины пароля, добавив регулярное выражение в параметр password_regex:

[security_compliance]
password_regex = ^(?=.*\d)(?=.*[a-zA-Z]).{7,}$

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

• содержащий как минимум 1 букву,
• содержащий как минимум 1 цифру,
• минимальной длиной семь (7) символов.

Если вы устанавливаете password_regex, вы должны предоставить текст, описывающий ваши требования к надежности пароля. Вы можете сделать это, установив password_regex_description:

[security_compliance]
password_regex_description = Passwords must contain at least 1 letter, 1
                             digit, and be a minimum length of 7
                             characters.

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

Требование уникальной истории паролей¶

Требования к истории паролей определяют количество паролей для пользователя, которые должны быть уникальными, прежде чем можно будет повторно использовать старый пароль. Вы можете применить это, установив параметр unique_last_password_count:

[security_compliance]
unique_last_password_count= 5

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

Точно так же вы можете установить количество дней, в течение которых пароль должен использоваться, прежде чем пользователь сможет его изменить, установив minimum_password_age:

[security_compliance]
minimum_password_age = 1

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

Предотвращение изменения пароля для самообслуживания¶

Если существует пользователь, который не должен иметь возможность изменить свой пароль с помощью API смены пароля keystone, keystone поддерживает установку этого параметра с помощью параметра пользователя lock_password.

Это обычно используется в случае, когда пароли управляются извне по отношению к Keystone.

Параметры конфигурации Keystone, влияющие на производительность¶

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

• [DEFAULT] max_project_tree_depth: уменьшите это число, чтобы повысить производительность, увеличьте это число, чтобы удовлетворить более сложные иерархические случаи использования нескольких арендаторов.
• [DEFAULT] max_password_length: уменьшите это число, чтобы повысить производительность, увеличьте это число, чтобы обеспечить более безопасные пароли.
• [cache] enable: включите этот параметр, чтобы повысить производительность, но вам также необходимо настроить другие параметры в разделе [cache], чтобы фактически использовать кэширование.
• [token] provider: все поддерживаемые поставщики токенов в первую очередь руководствуются соображениями производительности. И UUID, и Fernet требуют онлайн-проверки (кэшируемые HTTP-вызовы обратно в keystone для проверки токенов). В целом Fernet имеет самые высокие характеристики масштабируемости, но требует дополнительной работы для проверки, поэтому включение кэширования ([cache] enable) абсолютно необходимо.
• [fernet] max_active_keys: если вы используете токены Fernet, уменьшите этот параметр, чтобы повысить производительность, увеличьте этот параметр, чтобы поддерживать более продвинутые стратегии ротации ключей.

Параметры конфигурации Keystonemiddleware, влияющие на производительность¶

Эта конфигурация фактически находится в Paste pipeline служб, использующих проверку токена от keystone (т. е.: nova, cinder, swift и т. д.):

• cache: если промежуточное ПО auth_token от Keystone развернуто с кэшем swift, используйте этот параметр, чтобы промежуточное ПО auth_token совместно использовало серверную часть кэширования со swift. В противном случае используйте опцию memcached_servers.
• memcached_servers: установите этот параметр, чтобы совместно использовать кэш для процессов keystonemiddleware.auth_token.
• token_cache_time: увеличьте этот параметр, чтобы повысить производительность, уменьшите этот параметр, чтобы быстрее реагировать на события отзыва токена (тем самым повышая безопасность).
• revocation_cache_time: увеличьте этот параметр, чтобы повысить производительность, уменьшите этот параметр, чтобы быстрее реагировать на события отзыва токена (тем самым повышая безопасность).
• memcache_security_strategy: не устанавливайте этот параметр для повышения производительности, но установите его для повышения безопасности при совместном использовании memcached с другими процессами.
• include_service_catalog: отключите этот параметр для повышения производительности, если для защищенной службы не требуется каталог служб.

Политики¶

Каждая служба OpenStack - Keystone, Nova, Neutron, Cinder и т. д., имеет свои собственные политики доступа на основе ролей. Эти политики определяют, какой пользователь может получить доступ к каким объектам и каким образом, и эти правила определяются в файле policy.json соответствующей службы.

Всякий раз, когда выполняется вызов API для определенной службы OpenStack, механизм политики этой службы использует соответствующие определения политики, чтобы понять, может ли этот вызов быть принят и обслужен. Любые изменения в policy.json вступают в силу немедленно, что позволяет внедрять новые политики во время работы соответствующей службы.

Файл policy.json представляет собой текстовый файл в формате JSON (Javascript Object Notation). Каждая политика определяется однострочным оператором в формате:

«<target>»: «<rule>»

Цель (target) политики (rule, правила), также называемая «action», представляет собой вызов API, например, такой как «запуск виртуальной машины» или «присоединение диска».

Имена - «action» обычно требуют уточнений. Например, OpenStack Nova предоставляет API-вызовы для получения списка виртуальных машин, дисков и сетей. В /etc/nova/policy.json эти API представлены как compute: get_all, volume: get_all и network: get_all, соответственно.

Соответствия между вызовами API и действиями обычно не документированы.

Правило или политика определяют, при каких обстоятельствах вызов API разрешен. Обычно оно включает в себя пользователя, который выполняет вызов (в дальнейшем именуемый «пользователь API») и часто объект, с которым работает вызов API. Типичное правило проверяет, является ли пользователь API владельцем объекта.

Изменение политики (правила)¶

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

"compute:get_all" : ""

"compute:shelve": "!"

"identity:create_user" : "role:admin"

"os_compute_api:servers:stop": "not role:DoNotStopVM"

"deny_stop_vm": "not role:DoNotStopVM"

"os_compute_api:servers:stop": "rule:deny_stop_vm"

"compute:start" : "user_id:%(user_id)s"

"admin_required": "role:admin or is_admin:1",
"owner" : "user_id:%(user_id)s",
"admin_or_owner": "rule:admin_required or rule:owner",
"identity:change_password": "rule:admin_or_owner"

"identity:ec2_delete_credential": "rule:admin_required or
             (rule:owner and user_id:%(target.credential.user_id)s)"

Синтаксис¶

Файл policy.json состоит из политик и псевдонимов формата target: rule или alias: definition, разделенных запятыми и заключенных в фигурные скобки:

{
       "alias 1" : "definition 1",
       "alias 2" : "definition 2",
       ...
       "target 1" : "rule 1",
       "target 2" : "rule 2",
       ....
}

Target - это API-интерфейсы, описанные как «сервис: API» или просто «API». Например, «compute: create» или «add_image».

Правила определяют, разрешен ли вызов API.

Правила могут быть следующими:

• always true - действие всегда разрешено, это может быть записано как «» (пустая строка), [] или «@»;
• always fals - действие никогда не допускается, записывается как «!»;
• специальная проверка;
• сравнение двух значений;
• логические выражения, основанные на более простых правилах.

Специальные проверки:

• <role>:<role name> - проверка, содержат ли учетные данные API эту роль;
• <rule>:<rule name> - определение псевдонима;
• http: <целевой URL> - url, который делегирует проверку удаленному серверу. API авторизуется, когда сервер возвращает True.

Разработчики могут определить дополнительные специальные проверки.

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

"value1 : value2"

Возможные значения:

• константы: строки, числа, true, false
• атрибуты API
• атрибуты целевого объекта
• флаг is_admin

Атрибутами API могут быть project_id, user_id или domain_id.

Атрибуты целевого объекта - это поля из описания объекта в базе данных. Например, в случае API «compute: start» объект является виртуальная машина, которая должна быть запущена. Политика запуска виртуальных машин может использовать атрибут %(project_id), то есть проект, которому принадлежит виртуальная машина. Конечный s указывает, что это строка.

is_admin указывает, что административные привилегии предоставляются через механизм токенов администратора (опция –os-token команды keystone). Токен администратора позволяет инициализировать базу данных идентификаторов до того, как роль администратора существует.

Псевдоним (алиас) существует для удобства. Псевдоним - это короткое имя для сложного или сложного для понимания правила. Он определяется так же, как и политика:

alias name : alias definition

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

Пример методики демонстрации применения ролевой модели в OpenStack¶

В исходном состоянии подготовлены:

• TRS проект (частный случай) с созданной в нем виртуальной машиной.
• Тестовый пользователь accent-user, введенный в указанный проект с ролью user и имеющий привязку к указанной виртуальной машине.

В процессе демонстрации создается тестовая роль DoNotStopVM, эта роль наделяется функционалом, запрещающим выключать ВМ, тестовая роль добавляется тестовому пользователю accent-user и далее производятся проверки возможности отключения виртуальной машины от имени тестового пользователя до и после присвоения ему роли DoNotStopVM.

Порядок действий:

1. В открытом окне интерфейса Dashboard зайти в раздел меню «Идентификация-Роли».

2. Нажать на кнопку «Создать роль».

3. В открывшемся окне заполнить поле –«Название роли» – DoNotStopVM, нажать на кнопку «Создать роль».

4. Переключиться на окно терминала АРМ администратора и войти по ssh на контроллер, для этого выполнить команду:

   # ssh root@vip
   

5. Далее ввести пароль в строке: password.

6. Наделить роль функцией запрета отключения собственной виртуальной машины, отредактировав файл правил на контроллере - /etc/nova/policy.json, для этого выполнить команду:

   [root@controller1 ~]# vim /etc/nova/policy.json
   

   В открывшемся конфигурационном файле найти строку servers:stop, для этого перевести редактор VIM в командный режим (нажать escape) далее / и фразу поиска.

   Добавить строку, скопировав ее и отредактировав правую часть:

   "os_compute_api:servers:stop": "rule:admin_or_owner" (исходная)
   "os_compute_api:servers:stop": "not role:DoNotStopVM" (полученная)
   

   Выполнить команду для записи и выхода из редактора: wq.

7. Авторизоваться в Dashboard тестовым пользователем accent-user (пароль 12345678).

8. Перейти в раздел меню TRS во вкладку TRS машины.

9. В общем списке TRS машин найти соответствующую тестовому пользователю виртуальную TRS машину.

10. Убедиться, что работа идет от имени тестового пользователя, для этого в верхнем правом углу сверить отображенную запись имени пользователя и машина имеет Статус – «Активна», Питание – «Включено».

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

    В открывшемся окне «Подтвердите Выключить машину» нажать на кнопку «Выключить машину».

12. Убедиться, что Статус машины поменялся на «Отключена» и Питание – «Отключено».

13. Включить машину, нажав на кнопку «Запустить машину», выбрав соответствующее действие.

14. Переключиться в окно терминала АРМ администратора, в командной строке выполнить команду для назначения тестовому пользователю роли:

    # openstack role add –project TRS_PROJECT2 –user accent-user DoNotStopVM
    

15. Выйти из Dashboard, используя меню в правом верхнем углу.

16. Авторизоваться в Dashboard тестовым пользователем accent-user (пароль 12345678).

17. Перейти в раздел меню TRS во вкладку TRS машины.

18. В общем списке TRS машин найти соответствующую тестовому пользователю виртуальную машину.

19. Убедиться, что работа идет от имени тестового пользователя, для этого в верхнем правом углу сверить отображенную запись имени пользователяб и машина имеет Статус – «Активна», Питание – «Включено».

20. Выполнить действие «Выключить машину» для данной TRS машины.

21. Убедиться, что появляется диагностическое сообщение типа: «Ошибка…невозможно выполнить действие».

22. Ожидаемый результат:

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