В платформе существуют две встроенные сущности — команды и пользователи. Основным источником данных для авторизации является Dex, установленный в Deckhouse Kubernetes Platform.

Пользователи обычно появляются при первой авторизации через Dex; администратор также может создать учётную запись заранее. Создание команд вручную в платформе не поддерживается.

Принадлежность пользователя к командам определяется на основе информации из Dex и обновляется при каждой аутентификации пользователя.

Каждый пользователь может состоять в произвольном количестве команд. Принадлежность пользователя к командам определяется на основе групп в Dex.

Синхронизация

При первой авторизации пользователя в платформу для него создаётся внутренняя учётная запись. Команды пользователя синхронизируются при первой и каждой последующей авторизации пользователя.

Фильтрация групп при синхронизации

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

Настройка доступна в разделе «Администрирование» → «Команды» по кнопке «Правила синхронизации». Для настройки правил требуется разрешение edit:team-filter-rules.

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

Режимы правил:

  • «Включить» — оставить только команды, совпадающие с паттерном. Остальные исключаются.
  • «Исключить» — оставить только команды, не совпадающие с паттерном. Совпадающие исключаются.

«Паттерн» задаётся в виде регулярного выражения (regex). Например:

  • ^dev-.* — группы, начинающиеся с dev-;
  • ^team-(frontend|backend)$ — группы team-frontend и team-backend;
  • .*-prod$ — группы, заканчивающиеся на -prod.

Порядок правил можно менять перетаскиванием. При пустом паттерне правило не применяется (пропускается).

Если пользователь входил в состав команды, а затем команда была отфильтрована правилами, то при следующей авторизации пользователь автоматически перестанет быть участником этой команды. Сама команда при этом останется в системе, её необходимо будет удалить вручную в разделе «Администрирование» → «Команды».

Параметры пользователей

Последняя активность

Время последней активности пользователя в платформе. Отображается в таблице пользователей в разделе «Администрирование» → «Пользователи». Обновляется при авторизации, либо при автоматической ротации JWT-токена пользователя (интервал ротации зависит от конфигурации Dex и по умолчанию равен 10 минутам).

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

Сервисные пользователи

Сервисный пользователь — учётная запись платформы для автоматизации и интеграций (скрипты, технические сценарии).

От обычного пользователя сервисный отличается тем, что не может авторизоваться в веб-интерфейсе через Dex. В таблице «Администрирование» → «Пользователи» у таких записей в колонке «Последняя активность» обычно отображается «никогда».

При этом для сервисного пользователя доступны:

  • настройка учётных данных для внешних сервисов;
  • создание API-токенов для вызова API DDP;
  • роли и команды — по тем же правилам RBAC, что и для остальных пользователей.

Учётную запись можно пометить как сервисную при создании в разделе «Пользователи» или переключателем «Сервисный пользователь» в таблице. Для этого администратору нужно разрешение edit:users. Супер-администратор не может быть сервисным пользователем.

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

На странице «Администрирование» → «Лицензия» сервисные пользователи учитываются отдельно и не входят в показатель «Лицензируемые».