Связь между конечными точками, регионами и т.д. В ключевом режиме OpenStack

Ответ 1

Keystone - это служба управления идентификацией для OpenStack.

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

Если вы делаете запрос API в любом месте OpenStack, API-интерфейс keystone - это способ его обнаружения, если вам разрешено делать этот запрос API.

Давайте работать с земли.

Пользователи. Пользователи в Keystone сегодня, как правило, люди. В настоящий момент не хватает тонкой поддержки ACL, чтобы действительно называть многих пользователей в OpenStack "учетной записью службы" в традиционном смысле. Но есть учетная запись службы, которая используется в качестве backhaul-соединения с API-интерфейсом Keystone как часть самой инфраструктуры OpenStack. Мы не будем вникать в этого аномального пользователя.

Когда пользователь аутентифицируется на Keystone (вы нажимаете OS_AUTH_URL, чтобы поговорить с keystone.. обычно, порт 5000 из керосинового api box), пользователь говорит, что "я пользователь X, у меня есть пароль Y, и я принадлежу к арендатор Z".

X может быть именем пользователя или userid (уникальным uuid пользователя) Y - это пароль, но вы также можете выполнить аутентификацию с помощью токена. Z - это имя арендатора или идентификатор арендатора (уникальный уэйд арендатора). в прошлых API-интерфейсах Keystone вам не нужно было указывать имя арендатора, но ваш токен не был бы очень полезен, если бы вы не сделали это, поскольку токен не был связан с вашим арендатором, и тогда вам будет отказано в каких-либо списках ACL на этом арендатор.

Итак... пользователь - довольно очевидная вещь. Пароль - довольно очевидная вещь. Но какой арендатор?

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

Теперь скажите, что вы добавляете пользователя в идентификатор арендатора администратора. Получает ли пользователь права администратора? Ответ - нет. То, где играют роли. Хотя пользователь в администраторе-арендаторе может иметь доступ к виртуальным машинам администратора и квотам для разворачивания виртуальных машин, пользователь не сможет делать такие вещи, как запрос к трассировке списка пользователей. Но если вы добавите роль администратора для этого пользователя, они будут наделены правами ACL, чтобы действовать как администратор в API-интерфейсе keystone и других API. Поэтому подумайте о арендаторе как о группе ресурсов и о роли в качестве набора ACL.

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

keystone предоставляет последнюю полезную вещь. каталог. каталог трапецеидальных искажений похож на телефонную книгу для API-интерфейсов openstack. всякий раз, когда вы используете клиент командной строки, например, когда вы можете назвать список nova для списка своих экземпляров, nova сначала проверяет подлинность на трапецеидальность и получает маркер для использования API, но также сразу же запрашивает каталог трассировки списка конечных точек API. Для keystone, cinder, nova, glance, swift... и т.д. Nova действительно будет использовать только конечную точку nova-api, хотя в зависимости от вашего запроса вы можете использовать конечную точку API административного трапецеидального искажения... мы вернемся к этому, Но, по сути, каталог - это канонический источник информации, в котором API находятся в мире. Таким образом, вам всегда нужно сообщить клиенту, где находится конечная точка публичного API-трапеции, и он может выяснить остальную часть из каталога.

Теперь я сделал ссылку на общедоступный API и административный API для ключевого слова.

Yep keystone имеет два API... вроде. Он запускает API на порту 5000, а другой - в диапазоне 32000. 5000 - общественный порт. Здесь вы делаете такие вещи, как поиск каталога, и попросите токен, чтобы вы могли разговаривать с другими API. Это очень просто и несколько затвердело. Административный API будет использоваться для таких вещей, как изменение пароля пользователя или добавление новой роли пользователю.

Довольно прямо?

Ответ 2

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

похожи на точку контакта для использования службы. adminurl, поскольку имя говорит только для пользователей admin. внутренний URL-адрес предназначен для разных служб, чтобы разговаривать друг с другом, если они есть, и публичный URL-адрес для кого-либо другого.

Зачем вам нужен отдельный публичный и внутренний URL-адрес, объясняется здесь.

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

Ответ 3

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

Ответ 4

Я постараюсь поставить это на язык непрофессионала.

Сервис. Openstack требует большого количества услуг для получения облачной инфраструктуры (вычисление, хранение и сеть). Для обеспечения плавного управления ими в то же время для управления мелким зерном Openstack использует понятие услуг. Сервисы позволяют конечным пользователям манипулировать одним из этих трех основных ресурсов. Например: для хранения используются службы с печью и быстрым движением. Эти службы также могут быть сконфигурированы для использования Ceph или gluster в бэкэнд.

Конечная точка - точка, в которой вы попадаете в службу openstack, чтобы сделать что-то полезное или разрушительное. Услуга может работать, но для "входа" требуется конечная точка, которая будет выглядеть как http://my-fancy-IP:hard-to-remember-port-number/v3.0. Итак, никаких конечных точек, созданных в системе Openstack для конкретной службы openstack? Невозможно получить доступ к этой службе.

Регион - ничего общего с географией или местоположением. Термин, используемый для деления/группирования полных развертываний openstack, если у вас их много. Раздел может основываться на местоположении физических серверов.

Пользователь - конечный пользователь или вы.

Project/Tenant - контейнер для разделения ресурсов (вычислить, сеть хранения)

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

Роль - Ваши права на выполнение любой операции над службами openstack. Подумайте о роли, подумайте о пользователе.

Токен - это идентификатор (длинная строка), заданный с помощью ключевого слова. Вы можете получить доступ к любой службе openstack в соответствии с назначенной вам ролью с помощью этого токена.

Например, вы можете запросить nova и сказать: hey nova я получил token1 от keystone. Я хочу удалить сервер "don't-ever-delete-me-ever" . Nova принимает token1 и говорит, что hey keystone, у этого пользователя есть токен1 и он хочет удалить сервер "don't-ever-delete-me-ever" . Keystone, просматривает токен1 и, согласно назначенной пользователю роли, скажет: ok nova разрешить/не разрешать пользователю удалять сервер "don't-ever-delete-me-ever" .