Я действительно пытаюсь понять под капотом Keystone отношения между конечными точками, регионами, арендаторами, службами, пользователями и ролями. Я пытался найти соответствующие документы, но, к сожалению, потерпел неудачу.
Может ли кто-нибудь дать какие-либо указатели или объяснения?
Keystone — это служба управления идентификацией для OpenStack.
По сути, его роль заключается в предоставлении токенов пользователям, будь то люди, службы или что-либо вообще.
Если вы делаете запрос API где-либо в OpenStack, Keystone API — это то, как он обнаруживается, если вам разрешено делать этот запрос API.
Давайте поднимемся с земли.
Пользователи. Пользователи Keystone сегодня, как правило, люди. На данный момент нет достаточно тонкой поддержки ACL, чтобы действительно называть многих пользователей в OpenStack «сервисной» учетной записью в традиционном смысле. Но есть учетная запись службы, которая используется в качестве обратного соединения с Keystone API как частью самой инфраструктуры OpenStack. Мы не будем копаться в этом аномальном пользователе.
Когда пользователь аутентифицируется в Keystone (вы нажимаете OS_AUTH_URL, чтобы поговорить с keystone. Обычно это порт 5000 окна keystone api), пользователь говорит: «Я пользователь X, у меня есть пароль Y, и я принадлежу арендатору Z». .
X может быть именем пользователя или идентификатором пользователя (уникальный uuid пользователя). Y — это пароль, но вы также можете пройти аутентификацию с помощью токена. Z — это имя арендатора или идентификатор арендатора (уникальный UUID арендатора). в предыдущих API-интерфейсах Keystone вам НЕ НУЖНО указывать имя арендатора, но ваш токен не будет очень полезен, если вы этого не сделаете, поскольку токен не будет связан с вашим арендатором, и вам будет отказано в каких-либо ACL для этого жилец.
Итак... пользователь - это довольно очевидная вещь. Пароль — вещь достаточно очевидная. Но что такое арендатор?
Ну арендатор также известен как проект. На самом деле, были неоднократные попытки сделать название либо арендатором, либо проектом, но в результате невозможности придерживаться только одного термина они оба означают одно и то же. Что касается API, проект является арендатором. Поэтому, если вы войдете в Horizon, вы увидите раскрывающийся список для ваших проектов. Каждому проекту соответствует идентификатор арендатора. Ваши токены также связаны с определенным идентификатором арендатора. Таким образом, вам может понадобиться несколько токенов для пользователя, если вы собираетесь работать с несколькими арендаторами, к которым привязан пользователь.
Теперь предположим, что вы добавили пользователя в идентификатор арендатора admin. У этого пользователя есть права администратора? Ответ - нет. Вот где роли вступают в игру. Хотя пользователь в арендаторе администратора может иметь доступ к виртуальным машинам администратора и квотам на запуск виртуальных машин, этот пользователь не сможет выполнять такие действия, как запрос трапецеидального искажения для списка пользователей. Но если вы добавите этому пользователю роль администратора, он будет наделен правами ACL, чтобы действовать в качестве администратора в Keystone API и других API. Поэтому думайте о арендаторе как о группе ресурсов, а о ролях — как о наборе ACL.
регионы больше похожи на способы географической группировки физических ресурсов в среде инфраструктуры openstack. скажем, у вас есть два сегментированных центра обработки данных. вы можете поместить один в регион A вашей среды openstack, а другой — в регион B. Регионы с точки зрения их полезности быстро развиваются, особенно с появлением ячеек и доменов в более поздних выпусках openstack. Вам, вероятно, не нужно обладать этими знаниями, если только вы не собираетесь проектировать большие облака.
keystone предоставляет последнюю полезную вещь. каталог. каталог keystone похож на телефонную книгу для API openstack. всякий раз, когда вы используете клиент командной строки, например, когда вы можете вызвать список nova, чтобы перечислить ваши экземпляры, nova сначала аутентифицируется в keystone и получает токен для использования API, но также немедленно запрашивает каталог keystone для списка конечных точек API. Для keystone, cinder, nova, look, swift... и т. д. nova действительно будет использовать только конечную точку nova-api, хотя, в зависимости от вашего запроса, вы можете использовать конечную точку административного API keystone... мы вернемся к этому . Но, по сути, каталог — это канонический источник информации о том, где в мире находятся API. Таким образом, вам нужно только сообщить клиенту, где находится общедоступная конечная точка API Keystone, а остальное он сможет выяснить из каталога.
Теперь я упомянул общедоступный API и административный API для трапецеидальных искажений.
Да, у keystone есть два API... вроде того. Он запускает API на порту 5000 и еще один в диапазоне 32000. 5000 — общедоступный порт. Здесь вы делаете такие вещи, как поиск каталога и запросите токен, чтобы вы могли общаться с другими API. Это очень просто и несколько усложнено. Административный API будет использоваться для таких вещей, как изменение пароля пользователя или добавление новой роли пользователю.
Довольно прямолинейно?
Поздний ответ, но я надеюсь, что это поможет будущим читателям.
конечные точки подобны точке контакта для вас, чтобы использовать услугу. adminurl, как следует из названия, предназначен только для пользователей-администраторов. внутренний URL-адрес предназначен для того, чтобы различные службы могли общаться друг с другом, если это необходимо, а общедоступный URL-адрес предназначен для использования кем-либо еще.
Зачем вам нужны отдельные общедоступные и внутренние URL-адреса, объясняется здесь< /а>.
Вам не нужно назначать роль для конечных точек службы. Вы назначаете роли пользователям, которые обращаются к сервису и этому как ты это делаешь.
Это мое понимание арендатор, пользователь, роль, разрешение в openstack keystone. вам тоже может быть интересно.
Я постараюсь изложить это на языке непрофессионала.
Служба — Openstack нуждается в большом количестве служб для запуска облачной инфраструктуры (вычисления, хранилища и сети). Чтобы они могли плавно и в то же время иметь детальный контроль, Openstack использует понятие сервисов. Службы позволяют конечным пользователям манипулировать одним из этих трех основных ресурсов. Например: Для хранения используются сервисы Cinder и Swift. Эти сервисы в дальнейшем могут быть настроены на использование Ceph или gluster в серверной части.
Конечная точка — точка, в которой вы «входите» в службу openstack, чтобы сделать что-то полезное или разрушительное. Служба может быть запущена, но для «входа» требуется конечная точка, которая будет выглядеть как http://my-fancy-IP:hard-to-remember-port-number/v3.0. Итак, в системе Openstack не созданы конечные точки для конкретной службы openstack? Невозможно получить доступ к этому сервису.
Регион - Ничего общего с географией или местоположением. Термин, используемый для разделения/группировки полных развертываний openstack, если у вас их много. Разделение может быть основано на расположении физических серверов.
Пользователь - Конечный пользователь или Вы.
Project/Tenant — контейнер для разделения ваших ресурсов (вычислений, сети хранения)
Домен — Группа проектов, групп и пользователей. Обеспечивает разделение ресурсов для пользователей и может поддерживать несколько проектов. Пользователь с ролью администратора домена может создавать/удалять/обновлять любой проект, пользователей, группы и т. д. в этом конкретном домене.
Роль — ваши права на выполнение любых операций с сервисами openstack. Думайте о роли, думайте о пользователе.
Токен — это идентификатор (длинная строка), предоставленный вам Keystone. Вы можете получить доступ к любому сервису openstack в соответствии с назначенной вам ролью, используя этот токен.
Например, вы можете запросить nova и сказать: «Эй, nova, я получил токен1 от keystone. Я хочу удалить сервер «никогда не удаляй меня». Nova берет token1 и говорит: «Привет, keystone, у этого пользователя есть token1, и он хочет удалить сервер «никогда не удаляй меня». Keystone смотрит на token1 и в соответствии с ролью, назначенной пользователю, говорит: ok nova разрешить/не разрешить пользователю удалять сервер «никогда не удаляй меня никогда».
