Типы аутентификации и их настройка

Deckhouse Observability Platform предоставляет различные методы аутентификации для обеспечения безопасного доступа к системе.

Доступны следующие варианты аутентификации:

• Email/пароль: cтандартный метод аутентификации, где пользователи входят в систему, используя свой email и пароль. Этот метод включен по умолчанию.
• Внешняя аутентификация: для организаций, которые предпочитают использовать свои существующие системы управления идентификационной информацией, Deckhouse Observability Platform поддерживает аутентификацию через внешние источники. В настоящее время поддерживаются следующие методы:
  • OIDC (OpenID Connect): современный стандарт аутентификации, основанный на протоколе OAuth 2.0;
  • LDAP / Active Directory c использованием Dex: интеграция с корпоративными каталогами LDAP или Active Directory с использованием Dex как посредника (требуется дополнительная настройка со стороны Deckhouse Kubernetes Platform).

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

Также доступен следующий вариант аутентификации к API:

• API Tokens: метод аутентификации для взаимодействия с системой через API. Данный вид аутентификации включен всегда.

Ролевая модель пользователей

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

Пользователи могут иметь 4 типа ролей:

• Суперадминистратор: полный доступ ко всем сущностям системы, включая системные настройки.
• Администратор: доступ к конкретной сущности — организации, рабочему пространству или проекту. Автоматически распространяется на вложенные сущности.
• Пользователь: доступ к конкретной сущности — организации, рабочему пространству или проекту. Автоматически распространяется на вложенные сущности.
• Только просмотр: чтение конкретной сущности — организации, рабочему пространству или проекту. Автоматически распространяется на вложенные сущности.

Ролевая модель пользователей

Внешняя аутентификация

Включение внешней аутентификации

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

1. Задание маппинга для роли суперадминистратора:

   • Войдите в раздел «Системные настройки» —> «Настройка маппинга ролей».
   • Выберите «Добавить маппинг».
   • Заполните поля:
     • «Название группы»: идентификатор внешней группы (например, «super-administrator»).
     • «Тип объекта»: выберите «Вся система».
     • «Роль»: укажите «Суперадминистратор».
   • Подтвердите выбор, нажав «Обновить».

2. Включение внешней авторизации:

   • Если используется Dex, требуется предварительная настройка dexProvider.
   • Если включена OIDC, необходимо задать настройки oidc в ModuleConfig.
   • Включите внешнюю авторизацию в ModuleConfig, используя команду:

     kubectl patch ModuleConfig observability-platform -p '{"spec": {"settings": {"auth": {"mode": "externalAuth"}}}}' --type=merge
     

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

Настройка маппинга ролей

Следуйте нижеуказанным шагам для настройки маппинга ролей:

1. Перейдите в «Системные настройки» -> «Настройка маппинга ролей».
2. Нажмите «Добавить маппинг ролей»:
   • «Название группы»: название группы из внешней системы (например, «admins»).
   • «Тип объекта»: выберите объект («Вся система», «Организация», «Рабочее пространство», «Проект»).
   • «Родительский объект» (если применимо).
   • «Название объекта» (если применимо).
   • «Роль»: выберите один из типов роли («Суперадминистратор», «Администратор», «Пользователь», «Только просмотр»).

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

Tokens — это учетная запись в системе, имеющая различные права доступа к различным сущностям системы. Tokens взаимодействуют с системой только через API.

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