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

Информация и рекомендации по общей настройке Keystone для администраторов Keystone. С полной документацией по конфигурации Keystone и примерами файлов конфигурации можно ознакомиться в основном разделе «Конфигурация».

Устранение неполадок службы идентификации

Чтобы устранить неполадки со службой идентификации, просмотрите журналы в файле /var/log/keystone/keystone.log.

Используйте файл /etc/keystone/logging.conf для настройки расположения файлов журналов.

Примечание

Флаг insecure_debug уникален для службы идентификации. Если вы включите insecure_debug, сообщения об ошибках от API изменятся, чтобы возвращать конфиденциальную информацию. Например, сообщение об ошибке при неудачной аутентификации содержит информацию о том, почему аутентификация не удалась.

Журналы показывают компоненты запроса WSGI, и в идеале показывают ошибку, которая объясняет, почему запрос авторизации не удался. Если вы не видите запрос в логах, запустите Keystone с параметром --debug. Передайте параметр --debug перед параметрами команды.

Логирование

Вы настраиваете ведение журнала извне по отношению к остальной части службы Identity. Имя файла, определяющего конфигурацию ведения журнала, задается с помощью параметра log_config_append в разделе [DEFAULT] файла /etc/keystone/keystone.conf. Чтобы направить ведение журнала через системный журнал, установите use_syslog=true в разделе [DEFAULT].

Образец файла конфигурации ведения журнала доступен вместе с проектом в файле etc/logging.conf.sample. Как и в других проектах OpenStack, в Identity используется модуль ведения журнала Python, который предоставляет широкие возможности конфигурации, позволяющие определять уровни и форматы вывода.

Конфигурация для конкретного домена

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

Параметры конфигурации Identity для конкретного домена могут храниться в файлах конфигурации для конкретного домена или в базе данных Identity SQL с помощью вызовов API REST.

Примечание

Хранение и управление параметрами конфигурации в базе данных SQL является экспериментальным в Kilo и добавлено в службу Identity в выпуске Liberty.

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

Чтобы включить драйверы для конкретного домена, установите следующие параметры в файле /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

Примечание

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

Примечание

Keystone не поддерживает перемещение содержимого домена (т. е. «его» пользователей и групп) из одного бэкенда в другой, а также членство в группах за пределами бэкенда.

Примечание

При использовании метода конфигурации на основе файлов для конкретного домена, чтобы удалить домен, который использует серверную часть, специфичную для домена, необходимо сначала отключить его, удалить его конкретный файл конфигурации (т. е. его соответствующий keystone.<domain_name>.conf), а затем перезапустить сервер Identity. При управлении параметрами конфигурации через Identity API домен можно просто отключить и удалить через Identity API; поскольку любые параметры конфигурации, специфичные для домена, будут автоматически удалены.

Примечание

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

Примечание

Keystone объявила устаревшей опцию keystone-manage domain_config_upload. Рекомендуется вместо этого настраивать параметры конфигурации домена через API.

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

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

Примечание

В случае с серверной частью (бэкендом) LDAP имена пользователей и групп не хэшируются. В результате их длина ограничена 255 символами. Более длинные имена приведут к ошибке.

В то время как 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

Интеграция идентификации с LDAP

Служба идентификации OpenStack поддерживает интеграцию с существующими каталогами LDAP для служб аутентификации и авторизации. Внутренние части LDAP требуют инициализации перед настройкой службы идентификации OpenStack для работы с ней. С дополнительными сведениями можно ознакомиться в :разделе Настройка LDAP для использования с Keystone.

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

Функция идентификации (identity) позволяет администраторам полностью управлять пользователями и группами по каждому домену или службе идентификации OpenStack.

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

Примечание

Можно изолировать информацию, связанную с идентификацией, для LDAP в развертывании и хранить информацию о ресурсах в отдельном хранилище данных. Невозможно сделать наоборот, когда информация о ресурсах хранится в LDAP, а идентификационная информация хранится в SQL. Если серверные части (бэкенды) ресурсов или назначений интегрированы с LDAP, серверные части (бэкенды) идентификации также должны быть интегрированы с LDAP.

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

Важно

Если вы используете SELinux (включен по умолчанию в производные RHEL), то для того, чтобы служба OpenStack Identity могла получить доступ к серверам LDAP, вы должны включить логическое значение authlogin_nsswitch_use_ldap для SELinux на сервере, на котором запущена служба OpenStack Identity.

Чтобы включить и сделать параметр постоянным при перезагрузке, установите следующее логическое значение в качестве пользователя root:

# setsebool -P authlogin_nsswitch_use_ldap on

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

Чтобы определить сервер назначения LDAP

Определите сервер назначения LDAP в файле /etc/keystone/keystone.conf:

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

Для URL-адреса можно указать несколько серверов LDAP, чтобы обеспечить поддержку высокой доступности для одного бэкенда LDAP. Чтобы указать несколько серверов LDAP, просто измените параметр URL в разделе [ldap] на список, разделенный запятыми:

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

Дополнительные настройки интеграции с LDAP

Установите эти параметры в файле /etc/keystone/keystone.conf для одного сервера LDAP или в файлах /etc/keystone/domains/keystone.DOMAIN_NAME.conf для нескольких серверных частей. Примеры конфигураций отображаются под сводкой каждого параметра:

  • Query option (Опция запроса)

    • Используйте query_scope для управления уровнем области представленных данных (поиск только на первом уровне или поиск по всему поддереву) через LDAP.
    • Используйте page_size для управления максимальным количеством результатов на странице. Нулевое значение отключает пагинацию.
    • Используйте alias_dereferencing для управления параметром разыменования LDAP для запросов.

    Пример:

    [ldap]
    query_scope = sub
    page_size = 0
    alias_dereferencing = default
    chase_referrals =
    
  • Debug (Отладка)

    Используйте debug_level, чтобы установить уровень отладки LDAP для вызовов LDAP. Нулевое значение означает, что отладка не включена:

    [ldap]
    debug_level = 4095
    

    Этот параметр устанавливает OPT_DEBUG_LEVEL в базовой библиотеке Python. Это поле представляет собой битовую маску (целое число), а возможные флаги описаны на справочных страницах OpenLDAP. Обычно используемые значения включают 255 и 4095, при этом 4095 означает более подробное описание, а 0 означает отключение. Мы рекомендуем обращаться к документации для вашей серверной части LDAP при использовании этой опции.

    Предупреждение

    Включение debug_level отрицательно скажется на производительности!

  • Connection pooling (Пул соединений)

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

    Используйте use_pool, чтобы включить пул соединений LDAP. Настройте размер пула подключений, максимальное количество повторных попыток, повторные попытки подключения, время ожидания (-1 означает неопределенное ожидание) и время жизни в секундах:

    [ldap]
    use_pool = true
    pool_size = 10
    pool_retry_max = 3
    pool_retry_delay = 0.1
    pool_connection_timeout = -1
    pool_connection_lifetime = 600
    
  • Connection pooling for end user authentication (Пул соединений для аутентификации конечных пользователей)

    Аутентификация пользователя LDAP выполняется посредством операции связывания LDAP. В больших развертываниях проверка подлинности пользователя может использовать все доступные соединения в пуле соединений. OpenStack Identity предоставляет отдельный пул соединений специально для аутентификации пользователей.

    Используйте use_auth_pool, чтобы включить пул соединений LDAP для аутентификации конечных пользователей. Настройте размер пула соединений и время жизни в секундах. И use_pool, и use_auth_pool должны быть включены для объединения соединений для аутентификации пользователей:

    [ldap]
    use_auth_pool = false
    auth_pool_size = 100
    auth_pool_connection_lifetime = 60
    

    Когда вы закончите настройку, перезапустите службу OpenStack Identity.

    Предупреждение

    Во время перезапуска службы аутентификация и авторизация недоступны.

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

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

Важно

Чтобы служба OpenStack Identity могла получить доступ к серверам LDAP, необходимо указать целевой сервер LDAP в файле /etc/keystone/keystone.conf. Дополнительные сведения в разделе Настройка сервера Identity LDAP.

Чтобы интегрировать одну серверную часть (бэкенд) Identity с LDAP:

  1. Включите драйвер идентификации LDAP в файле /etc/keystone/keystone.conf. Это позволяет использовать LDAP в качестве серверной части идентификации:

    [identity]
    #driver = sql
    driver = ldap
    
  2. Создайте организационные подразделения (OU) в каталоге LDAP и укажите соответствующее расположение в файле /etc/keystone/keystone.conf:

    [ldap]
    user_tree_dn = ou=Users,dc=example,dc=org
    user_objectclass = inetOrgPerson
    
    group_tree_dn = ou=Groups,dc=example,dc=org
    group_objectclass = groupOfNames
    

    Примечание

    Эти атрибуты схемы расширяемы для совместимости с различными схемами.

    Например, эта запись сопоставляется с атрибутом субъекта в Active Directory:

    user_objectclass = person
    

    Перезапустите службу идентификации OpenStack.

    Предупреждение

    Во время перезапуска службы аутентификация и авторизация недоступны.

Чтобы интегрировать несколько серверных частей (бэкендов) Identity с LDAP:

  1. Установите следующие параметры в файле /etc/keystone/keystone.conf:

    • Включите драйвер LDAP:

      [identity]
      #driver = sql
      driver = ldap
      
    • Включите драйверы для домена:

      [identity]
      domain_specific_drivers_enabled = True
      domain_config_dir = /etc/keystone/domains
      
  2. Перезапустите службу идентификации OpenStack.

    Предупреждение

    Во время перезапуска службы аутентификация и авторизация недоступны.

  3. Перечислите домены с помощью информационной панели или интерфейса командной строки OpenStackClient. Обратитесь к списку команд для получения списка команд OpenStackClient.

  4. Создайте домены с помощью панели управления OpenStack или интерфейса командной строки OpenStackClient.

  5. Для каждого домена создайте файл конфигурации для конкретного домена в каталоге /etc/keystone/domains. Используйте соглашение об именовании файлов keystone.DOMAIN_NAME.conf, где DOMAIN_NAME — имя домена, назначенное на предыдущем шаге.

    Примечание

    Параметры, заданные в файле /etc/keystone/domains/keystone.DOMAIN_NAME.conf, переопределяют параметры в файле /etc/keystone/keystone.conf.

  6. Определите целевой LDAP-сервер в файле /etc/keystone/domains/keystone.DOMAIN_NAME.conf. Например:

    [ldap]
    url = ldap://localhost
    user = dc=Manager,dc=example,dc=org
    password = samplepassword
    suffix = dc=example,dc=org
    
  7. Создайте организационные единицы (OU) в каталогах LDAP и определите соответственно их местоположения в файле /etc/keystone/domains/keystone.DOMAIN_NAME.conf. Например:

    [ldap]
    user_tree_dn = ou=Users,dc=example,dc=org
    user_objectclass = inetOrgPerson
    
    group_tree_dn = ou=Groups,dc=example,dc=org
    group_objectclass = groupOfNames
    
  8. Перезапустите службу идентификации OpenStack.

    Предупреждение

    Во время перезапуска службы аутентификация и авторизация недоступны.

Дополнительные настройки интеграции с LDAP

Установите эти параметры в файле /etc/keystone/keystone.conf для одного сервера LDAP или в файлах /etc/keystone/domains/keystone.DOMAIN_NAME.conf для нескольких серверных частей. Примеры конфигураций отображаются под сводкой каждого параметра:

  • Filters (Фильтры)

    Используйте фильтры для управления объемом данных, представляемых через LDAP:

    [ldap]
    user_filter = (memberof=cn=openstack-users,ou=workgroups,dc=example,dc=org)
    group_filter =
    
  • Identity attribute mapping (Сопоставление атрибутов идентификации)

    Маскируйте значения состояния учетной записи (включая любые дополнительные сопоставления атрибутов) для совместимости с различными службами каталогов. Лишние учетные записи фильтруются с помощью user_filter.

    Настройка игнорирования атрибута для списка атрибутов, удаленных при обновлении.

    Например, вы можете замаскировать атрибуты состояния учетной записи Active Directory в файле /etc/keystone/keystone.conf:

    [ldap]
    user_id_attribute      = cn
    user_name_attribute    = sn
    user_mail_attribute    = mail
    user_pass_attribute    = userPassword
    user_enabled_attribute = userAccountControl
    user_enabled_mask      = 2
    user_enabled_invert    = false
    user_enabled_default   = 512
    user_default_project_id_attribute =
    user_additional_attribute_mapping =
    
    group_id_attribute     = cn
    group_name_attribute   = ou
    group_member_attribute = member
    group_desc_attribute   = description
    group_additional_attribute_mapping =
    

    Можно моделировать более сложные схемы LDAP. Например, в объекте user очень распространен объектный класс posixAccount из RFC2307. Если это базовый объектный класс, то поле uid, вероятно, должно быть uidNumber, а поле имени пользователя должно быть либо uid, либо cn. Ниже показана конфигурация:

    [ldap]
    user_id_attribute = uidNumber
    user_name_attribute = cn
    
  • Enabled emulation (Включенная эмуляция)

    OpenStack Identity поддерживает эмуляцию для интеграции с серверами LDAP, которые не предоставляют включенный атрибут для пользователей. Это позволяет OpenStack Identity объявлять включенные атрибуты, когда сущность пользователя в LDAP этого не делает. Параметр user_enabled_emulation должен быть включен, а параметр user_enabled_emulation_dn должен быть допустимой группой LDAP. Пользователи в группе, указанной user_enabled_emulation_dn, будут помечены как включенные. Например, следующий код пометит любого пользователя, являющегося членом группы enabled_users, как включенного:

    [ldap]
    user_enabled_emulation = True
    user_enabled_emulation_dn = cn=enabled_users,cn=groups,dc=openstack,dc=org
    

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

    [ldap]
    user_enabled_attribute = userAccountControl
    user_enabled_mask = 2
    user_enabled_default = 512
    

    В этом случае атрибут является целым числом, а включенный атрибут указан в бите 1. Если настроенная маска user_enabled_mask отлична от 0, атрибут извлекается из user_enabled_attribute и выполняется операция добавления с user_enabled_mask. Если сумма операции соответствует маске, то учетная запись отключается.

    Значение user_enabled_attribute также сохраняется перед применением операции добавления в enabled_nomask. Это делается в случае, если пользователя нужно включить или отключить. Наконец, установка user_enabled_default необходима для создания значения по умолчанию для целочисленного атрибута (512 = NORMAL ACCOUNT в Active Directory).

Когда вы закончите настройку, перезапустите службу OpenStack Identity.

Предупреждение

Во время перезапуска службы аутентификация и авторизация недоступны.

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

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

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

Чтобы настроить шифрование TLS для трафика LDAP:

  1. Откройте файл конфигурации /etc/keystone/keystone.conf.

  2. Найдите раздел [ldap].

  3. В разделе [ldap] задайте для конфигурационного ключа use_tls значение True. Это активирует TLS.

  4. Настройте службу идентификации для использования вашего файла центров сертификации. Для этого установите ключ конфигурации tls_cacertfile в разделе ldap на путь к файлу центра сертификации.

    Примечание

    Вы также можете установить значение параметра tls_cacertdir (также в разделе ldap) для каталога, в котором хранятся все файлы центров сертификации. Если установлены и tls_cacertfile, и tls_cacertdir, последний будет игнорироваться.

    Укажите, какие проверки сертификата клиента следует выполнять для входящих сеансов TLS с сервера LDAP. Для этого установите для конфигурационного ключа tls_req_cert в разделе [ldap] значения demand, allow или never:

    • demand — сервер LDAP всегда получает запросы сертификатов. Сеанс завершается, если сертификат не предоставлен или предоставленный сертификат не может быть проверен по существующему файлу центров сертификации.
    • allow — сервер LDAP всегда получает запросы сертификатов. Сеанс будет продолжаться как обычно, даже если сертификат не предоставлен. Если сертификат предоставлен, но его невозможно проверить по существующему файлу центров сертификации, сертификат будет проигнорирован, и сеанс продолжится в обычном режиме.
    • never — сертификат никогда не запрашивается.

Когда вы закончите настройку, перезапустите службу OpenStack Identity.

Примечание

Если вы не можете подключиться к LDAP через OpenStack Identity или наблюдаете ошибку SERVER DOWN, установите для TLS_CACERT в /etc/ldap/ldap.conf то же значение, которое указано в tls_certificate раздела [ldap] файла keystone.conf.

В дистрибутивах, включающих openstack-config, вы можете настроить шифрование TLS для трафика LDAP, выполнив вместо этого следующие команды:

# 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``

Где:

  • CA_FILE — абсолютный путь к файлу центра сертификации, который следует использовать для шифрования трафика LDAP.
  • CERT_BEHAVIOR указывает, какие проверки сертификата клиента следует выполнять для входящего сеанса TLS с сервера LDAP (demand, allow или never).

Уровень кэширования

OpenStack Identity поддерживает уровень кэширования, который находится над настраиваемыми подсистемами (например, токены). Это дает вам возможность настроить кэширование для всех или некоторых подсистем. OpenStack Identity использует библиотеку oslo.cache, которая обеспечивает гибкую внутреннюю часть кэша. Большинство параметров конфигурации кэширования задаются в разделе [cache] файла /etc/keystone/keystone.conf. Включенная опция раздела [cache] должна быть установлена в True, чтобы любая подсистема кэшировала ответы. Каждый раздел, который может быть кэширован, будет иметь логическое значение кэширования, которое переключает режим кэширования этой конкретной подсистемы.

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

[cache]
enabled=true

[catalog]
caching=false

[domain_config]
caching=false

[federation]
caching=false

[resource]
caching=false

[revoke]
caching=false

[role]
caching=false

[token]
caching=true

Примечание

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

Текущие функциональные серверные части (бэкенды):

dogpile.cache.null - «нулевой» бэкенд, который эффективно отключает все операции с кэшем (по умолчанию).

dogpile.cache.memcached - серверная часть (бэкенд) memcached с использованием стандартной библиотеки python-memcached.

dogpile.cache.pylibmc - серверная часть (бэкенд) memcached с использованием библиотеки pylibmc.

dogpile.cache.bmemcached - memcached с использованием библиотеки python-binary-memcached.

dogpile.cache.redis - бэкенд Redis.

dogpile.cache.dbm - серверная часть локального файла DBM.

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

dogpile.cache.memory_pickle - кэш в памяти, но сериализует объекты с помощью pickle lib. Он не подходит для использования вне тестирования. Причина та же, что и с dogpile.cache.memory.

oslo_cache.mongo - MongoDB как кэширующая серверная часть (бэкенд).

oslo_cache.memcache_pool - бэкенд memcached, который выполняет пул соединений.

oslo_cache.etcd3gw использует etcd 3.x для хранения.

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

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

Подсистема токенов является наиболее часто используемым 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]).

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

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

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

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

Предупреждение

Имейте в виду, что если для конкретной подсистемы используется серверная часть только для чтения, кэш не будет немедленно отражать изменения, выполненные через серверную часть. Любое заданное изменение может занять время cache_time (если установлено в разделе конфигурации подсистемы) или глобальное expire_time (установлено в разделе конфигурации [cache]), прежде чем оно будет отражено. Если этот тип задержки является проблемой, мы рекомендуем отключить кэширование для этой конкретной подсистемы.

Пример настройки серверной части (бэкенда) 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

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

Соответствие требованиям безопасности и PCI-DSS

Начиная с версии Newton, служба Identity содержит дополнительные функции обеспечения соответствия требованиям безопасности, в частности, для удовлетворения требований стандарта безопасности данных (PCI-DSS) v3.1 индустрии платежных карт. Дополнительная информация о PCI-DSS в разделе «Усиление безопасности PCI-DSS».

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

Включите эти функции, изменив параметры конфигурации в разделе [security_compliance] в keystone.conf.

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

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

Примечание

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

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

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

[security_compliance]
unique_last_password_count= 5

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

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

[security_compliance]
minimum_password_age = 1

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

Примечание

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

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

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

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

Производительность и масштабирование

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

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

Безопасное URL-именование проектов и доменов

В будущем Keystone может предложить возможность идентифицировать проект в иерархии с помощью стиля именования URL-адресов от корня иерархии (например, указание «projectA/projectB/projectC» в качестве имени проекта в запросе аутентификации). Чтобы подготовиться к этому, Keystone поддерживает дополнительную возможность гарантировать, что и проекты, и домены названы без включения каких-либо зарезервированных символов, указанных в разделе 2.2 rfc3986.

Безопасность имен проектов и доменов можно контролировать с помощью двух опций конфигурации:

[resource]
project_name_url_safe = off
domain_name_url_safe = off

Если установлено значение off (по умолчанию), проверка безопасности имен URL-адресов не выполняется. Если установлено значение new, попытка создать новый проект или домен с небезопасным именем (или изменить имя проекта или домена на небезопасное) приведет к возврату кода состояния 400 (неверный запрос). Установка для параметра конфигурации значения strict, помимо предотвращения создания и обновления сущностей с небезопасными именами, приведет к тому, что попытка проверки подлинности, которая указывает небезопасное имя проекта или домена, будет возвращать код состояния 401 (неавторизованный).

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

Ограничение размера возвращаемого списка

Keystone предоставляет метод установки ограничения на количество объектов, возвращаемых в коллекции, что полезно для предотвращения слишком длительного времени ответа на запросы списка, для которых не указан достаточно узкий фильтр. Это ограничение можно установить глобально, установив list_limit в разделе [DEFAULT] keystone.conf, при этом ограничение по умолчанию не установлено. Отдельные разделы драйвера могут переопределить это глобальное значение с определенным ограничением, например:

[resource]
list_limit = 100

Если ответ на вызов list_{entity} был усечен, код состояния ответа по-прежнему будет 200 (ОК), но для атрибута truncated в коллекции будет установлено значение true.

Фильтрация точек входа

Endpoint Filtering позволяет создавать специальные каталоги для каждого запроса токена в рамках проекта.

Настройте драйвер каталога фильтров точек входа в секции [catalog]. Например:

[catalog]
driver = catalog_sql

В разделе [endpoint_filter] задайте для параметра return_all_endpoints_if_no_filter значение False, чтобы вернуть пустой каталог, если сопоставления не выполнены. Например:

[endpoint_filter]
return_all_endpoints_if_no_filter = False

С подробной информацией об определении API можно ознакомиться в Спецификации API для фильтрации точек входа.

Политика точек входа (Endpoint Policy)

Функция Endpoint Policy обеспечивает связи между точками входа службы и политиками, которые уже хранятся на сервере Identity и на которые ссылается идентификатор политики.

Настройте серверный драйвер политики точки входа в разделе [endpoint_policy]. Например:

[endpoint_policy]
driver = sql

С подробной информацией об определении API можно ознакомиться в Спецификации API для политики точек входа.

Ролевая модель OpenStack

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

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

Служба OpenStack Keystone определяет роль пользователя в проекте, но эта роль полностью зависит от полномочий в отдельных службах, что и определяет, что означает эта роль. Это называется политикой сервисов. Чтобы получить подробную информацию о привилегиях для каждой роли, обратитесь к файлу policy.json, доступному для каждой службы, в файле /etc/SERVICE/policy.json. Например, политика, определенная для службы идентификации OpenStack, определена в файле /etc/keystone/policy.json.

../../_images/role_organization.png

Организация ролевой модели

Политики

Каждая служба 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" : ""

Цель («action) - «compute: get_all», API «list all instance» API службы Compute. Правило - пустая строка, означающая «всегда». Эта политика позволяет любому пользователю просматривать список виртуальных машин.

Вы также можете отклонить разрешение на использование API:

"compute:shelve": "!"

Восклицательный знак означает «никогда» или «никто», что фактически отключает Nova API «архивировать виртуальную машину».

Многие API могут вызываться только пользователями с правами администратора. Это может быть выражено правилом «role:admin». Следующая политика гарантирует, что только администраторы могут создавать новых пользователей в базе данных Identity:

"identity:create_user" : "role:admin"

Вы можете ограничить API для любой роли. Например, служба Nova определяет роль с именем DoNotStopVM. Тот, кто имеет эту роль, не имеет права выключать виртуальные машины:

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

Это правило не использует логический оператор. Более сложные правила могут быть построены с использованием операторов and, or и круглых скобок.

Вы можете определить псевдонимы для правил:

"deny_stop_vm": "not role:DoNotStopVM"

Механизм политики «понимает», что «deny_stop_vm» не является API, и, следовательно, интерпретирует его как псевдоним. Приведенная выше политика создания стека может быть записана как:

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

Эти правила прописаны в файле /etc/nova/policy.json.

Правила могут сравнивать атрибуты API с атрибутами объекта. Например:

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

Эта запись утверждает, что только владелец виртуальной машины может запустить её. Строка user_id перед двоеточием является атрибутом API - идентификатором пользователя API. Он сравнивается с идентификатором пользователя объекта (в данном случае, виртуальной машины), а именно, с полем user_id этого объекта в базе данных. Если два значения равны, разрешение предоставляется.

Пользователь с правами администратора всегда имеет право вызывать API. Вот как /etc/keystone/policy.json делает эту политику явной:

"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"

Первая строка определяет псевдоним для «пользователя, который является администратором». Флаг is_admin используется только при первоначальной настройке службы Keystone. Это означает, что у пользователя есть права администратора, предоставленные служебным токеном (параметр –os-token клиента командной строки keystone).

Вторая строка создает псевдоним для «пользователь, который владеет объектом», сравнивая идентификатор пользователя API с идентификатором пользователя объекта.

В третьей строке определяется третий псевдоним admin_or_owner, объединяя два первых псевдонима с логическим оператором или.

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

В качестве последнего примера давайте рассмотрим более сложное правило:

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

Это правило определяет, кто может использовать Keystone API с целью «удалить учетные данные EC2». Здесь логические операторы и круглые скобки объединяют три более простых правила. admin_required и owner - это те же псевдонимы, что и в предыдущем примере; user_id:% (target.credential.user_id) s сравнивает пользователя API с идентификатором пользователя объекта учетных данных, связанного с целью.

Синтаксис

Файл 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.