Содержание


Настройка поддержки доменно-ориентированных корпоративных каталогов в Keystone OpenStack

Как с помощью Keystone OpenStack обеспечить поддержку нескольких доменов LDAP и Active Directory

Comments

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

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

  • обзор классической поддержки корпоративных каталогов в Keystone;
  • усовершенствования, добавленные в Keystone для поддержки доменно-ориентированных каталогов;
  • основные шаги по настройке Keystone для использования этой новой поддержки;
  • обзор будущих направлений совершенствования доменно-ориентированных каталогов в Keystone OpenStack.

Классическая модель авторизации Keystone

Прежде чем приступить к изучению новых функций поддержки доменно-ориентированных каталогов Keystone, полезно познакомиться с обзором классической однодоменной поддержки. На самом деле ядро Keystone распадается на два компонента: управление учетными данными и управление назначениями. управление учетными данными (то есть субъектами проверки подлинности) позволяет хранить учетные записи пользователей и групп в локальной базе данных SQL, или обеспечить поддержку со стороны удаленной службы LDAP или Active Directory. Проекты, домены, роли и назначения для этих ролей хранятся в службе управления назначениями (то есть определения того, что именно пользователь может делать после проверки подлинности). Опять же, они могут храниться в локальной базе данных SQL или, реже, в удаленной службе LDAP/AD, если у вас есть доступ к ней для чтения и записи. До сих пор из-за проблем отображения доменной структуры Keystone на LDAP (в части управления учетными данными), если для управления учетными данными использовался LDAP, то вы были ограничены одним доменом по умолчанию. Это не позволяло использовать LDAP/AD в более сложных установках.

Потребность в многодоменной поддержке корпоративных каталогов

Учитывая, что нельзя изменить тот факт, что схема LDAP/AD плохо отображается на типичную модель, требуемую уровнем IaaS, которому, по соображениям эффективности, нужна модель совместного использования, необходимо изменить модель взаимодействия Keystone с каталогом. По сути, нужно решить вопросы "доменной ориентированности" Keystone и взаимодействия с соответствующим корпоративным каталогом, как если бы использовался только он. Это подразумевает определение всех типичных параметров LDAP/AD (URL, отображение атрибутов каталога и т.д.) для каждого домена и обеспечение того, чтобы всякий раз, когда вы, скажем, считываете запись пользователя данного домена, вызов перенаправлялся в нужный корпоративный каталог. Такой уровень поддержки был введен в версии Grizzly, но ему были присущи некоторые проблемы. Наиболее серьезной из них был конфликт между основной концепцией API Keystone и такой мультидоменной поддержкой – а именно, чтобы можно было передать API идентификатор пользователя или группы, и Keystone использовал бы его для поиска этого пользователя/группы. Когда серверов каталога несколько, в каком из них следует искать? Поиск во всех по соображениям производительности не представляется жизнеспособным вариантом. Поэтому в первоначальной реализации пытались определить требуемый домен - например, так как для извлечения записи пользователя по его идентификатору обычно применяется маркер контекста домена, то контекст этого маркера можно использовать для определения соответствующего корпоративного каталога данного домена. Однако этот метод имеет явные ограничения; например, нужно иметь возможность аутентификации только по идентификатору пользователя и паролю. И даже если эти ограничения удалось бы обойти, можно ли доверить любому заданному каталогу предприятия создание идентификатора объекта, уникального в масштабе всех корпоративных каталогов?

Поддержка многодоменных корпоративных каталогов

В версии OpenStack Juno вышеперечисленные проблемы Keystone решены путем добавления уровня отображения каталогов, который генерирует для своих клиентов уникальные идентификаторы пользователей и групп и хранит сведения о том, в каком драйвере узла учетных записей содержится тот или иной объект (и локальный ID внутри этого узла). Этот уровень отображения каталогов, по существу, невидим для тех, кто обращается к API Keystone, а отображение строится динамически, когда Keystone встречает объекты в своих драйверах учетных записей. Единственное, что может заметить вызывающий, – это увеличение размера идентификаторов пользователей и групп. (По умолчанию это 64-байтовые хэши sha256, в отличие от классических 32-байтовых UUID.) Следует отметить, что это отображение каталога не связано с отображением федерации Keystone, которое используется для управления отображением атрибутов утверждения IDP на назначения ролей Keystone.

Давайте теперь рассмотрим практический пример использования доменно-ориентированных каталогов. У поставщика услуг, который предлагает своим клиентам облачные услуги, каждый клиент обычно представлен доменом в Keystone. Это позволяет клиентам иметь своих собственных пользователей, группы и проекты. Поставщику нужна возможность разрешать клиентам использовать свой существующий корпоративный каталог для проверки подлинности в их домене – чтобы каждый домен клиента указывал на собственную службу LDAP/AD этого клиента. Первое, что нужно сделать, — включить в Keystone поддержку доменно-ориентированной конфигурации (по умолчанию она отключена), установив следующие два параметра в основном файле конфигурации Keystone:

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

Когда доменно-ориентированные драйверы включены, всякий раз при запуске Keystone он будет сканировать содержимое domain_config_dir на наличие любых доменно-ориентированных файлов конфигурации. Для каждого домена, которому требуется свой уникальный корпоративный каталог, поставщик услуг создает доменно-ориентированный файл конфигурации, содержащий конкретные детали корпоративного каталога этого домена. Например, если поставщик услуг создает домен «customerA» для представления этого клиента, то затем он создает доменно-ориентированный файл конфигурации с именем keystone.customerA.conf. (Имя важно и всегда имеет форму: keystone.{domain-name}.conf -- доменное имя должно соответствовать имени домена, созданного в keystone). Содержимое этого файла конфигурации может выглядеть следующим образом:

   [ldap] url = ldap://ldapservice.thecustomer.com
   user = cn=Manager,dc=openstack,dc=org
   password = mysecret
   suffix = dc=openstack,dc=org
   group_tree_dn = ou=UserGroups,dc=openstack,dc=org
   ;user_tree_dn = ou=Users,dc=openstack,dc=org
   user_mail_attribute = mail

   [identity]
   driver = keystone.identity.backends.ldap.Identity

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

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

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

   [identity]
   driver = keystone.identity.backends.sql.Identity

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

Советы и рекомендации по практическому применению

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

Действуйте в правильном порядке

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

  1. Присвоить параметру domain_specific_drivers_enabled основного файла конфигурации Keystone значение true и перезапустить Keystone.
  2. Создать домены, для которых требуется специальная конфигурация.
  3. Создать доменно-ориентированные файлы конфигурации для каждого из этих доменов.
  4. Перезапустить Keystone.

Драйвером по умолчанию служит LDAP, и если сначала не присвоить значение true параметру domain_specific_drivers_enabled, то Keystone не позволит создать новые домены (так как он «знает», что драйвер по умолчанию LDAP может работать только с доменом по умолчанию).

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

Если вы создали домен и файл конфигурации, но по-прежнему не можете получить доступ к данным из корпоративного каталога, то, возможно, стоит проверить файл журнала событий Keystone. При запуске Keystone он сканирует domain_config_dir, просматривая каждый файл. Если имя файла не соответствует форме keystone.{имя домена}.conf, то он игнорируется. Если Keystone не может найти домен с именем, указанным в имени файла, он также игнорируется. В обоих случаях Keystone выдаст предупреждение с именем проблемного файла. Например,

 Invalid domain name (CustomerB) found in config file name

Периодически обновляйте таблицу отображения каталогов

Как говорилось выше, Keystone строит отображение каталогов динамически по внешне опубликованным идентификаторам пользователей и групп для основных локальных объектов в соответствующей корпоративной службе каталогов. Так как с точки зрения Keystone эти корпоративные каталоги обычно доступны только для чтения, любое управление пользователями осуществляется извне с помощью инструментов, применяемых для обслуживания соответствующих корпоративных каталогов. На практике это означает, что если из корпоративного каталога удаляются объекты пользователей и групп, то в таблице отображения каталогов Keystone остаются старые записи. Это не страшно, но со временем таблица Keystone может раздуться. Поэтому инструмент keystone-manage был усовершенствован с добавлением поддержки нескольких способов удаления записей из таблицы отображения каталогов keystone. Наиболее подходящий способ – удалить отображение для указанного локального идентификатора в указанном домене. Например,

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

Если это происходит относительно часто, то такие обновления можно автоматизировать. Иначе, можно просто периодически удалять все отображения для данного домена. Не приведет ли это к потере внешне опубликованных ID локальных объектов? На самом деле этой проблемы не существует, поскольку алгоритм отображения устроен так, что Keystone может регенерировать отображения и гарантировать повторное назначение тех же внешне опубликованных ID пользователей/группы, что и прежде. При этом предполагается, что пользователь не переходит из одного корпоративного каталога в другой; в противном случае он будет считаться другим пользователем. Вот как удалить все отображения для данного домена:

   keystone-manage mapping_purge --domain-name CustomerA

Заключение

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


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Облачные вычисления, Open source
ArticleID=1017249
ArticleTitle=Настройка поддержки доменно-ориентированных корпоративных каталогов в Keystone OpenStack
publish-date=10122015