Модуль user-authn

Модуль user-authn реализует единую систему аутентификации, интегрированную с Kubernetes и веб-интерфейсами, используемыми в модулях Deckhouse Platform (DP), например, в модуле console.

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

Архитектура модуля

В DP для служебных сервисов и пользовательских приложений используются две схемы аутентификации:

• с использованием dex-authenticator;
• с использованием клиента Dex.

Архитектура модуля user-authn на уровне 2 модели C4 и его взаимодействия с другими компонентами DP изображены на следующих диаграммах.

Вариант с использованием dex-authenticator:

Вариант с использованием клиента Dex:

При подключении к API Kubernetes с помощью утилиты d8, kubectl или других клиентов Kubernetes с использованием сгенерированного kubeconfig используются отдельные схемы аутентификации:

• аутентификация по токенам, подробно описана в соответствующем разделе документации;
• базовая аутентификация (Basic Authentication), пример настройки базовой аутентификации с использованием провайдера LDAP приведён в разделе документации модуля.

Вариант подключения к API Kubernetes с аутентификацией по токенам:

Вариант подключения к API Kubernetes с базовой аутентификацией:

Компоненты модуля

Модуль состоит из следующих компонентов:

1. Dex — федеративный провайдер OpenID Connect, поддерживающий работу со статическими пользователями и интеграцию с внешними провайдерами аутентификации, такими как SAML, GitLab или GitHub. Модуль использует модифицированную версию Dex для поддержки:

   • групп для статических учетных записей пользователей;
   • двухфакторной аутентификации (2FA);
   • политики паролей;
   • принудительного изменения пароля;
   • SPNEGO (Kerberos) для LDAP‑коннектора. При использовании этого механизма Dex принимает билеты по заголовку Authorization: Negotiate, валидирует их по keytab, и завершает вход без отображения формы ввода логина/пароля и т.д.

   Актуальный список изменений в Dex приведен в репозитории модуля.

   Состоит из следующих контейнеров:

   • dex — основной контейнер, реализующий функции Dex;
   • kube-rbac-proxy — сайдкар-контейнер с авторизующим прокси на основе Kubernetes RBAC для организации защищенного доступа к метрикам провайдера. Является Open Source-проектом.

2. Dex-authenticator — middleware-сервис для аутентификации запросов к приложениям через сервис аутентификации кластера DP.

   При соответствующей настройке Ingress-контроллера (через модуль auth_request NGINX) запросы сначала направляются в dex-authenticator для аутентификации.

   Состоит из следующих контейнеров:

   • dex-authenticator — основной контейнер сервиса;
   • redis — сайдкар-контейнер c базой данных Redis, используемый для временного хранения ID Token и быстрого доступа к ним (за счет размещения базы в памяти);
   • self-signed-generator — init-контейнер, генерирующий самоподписанный сертификат при запуске пода.

3. User-authn-controller — контроллер, состоящий из одного контейнера user-authn-controller и выполняющий следующие операции:

   • управление кастомными ресурсами модуля:

     • Group — ресурс, описывающий статическую группу;
     • User — ресурс, описывающий статического пользователя;
     • UserAccount — ресурс, описывающий представление объектов Dex Password и OfflineSessions для веб-интерфейса DKP;
     • UserOperation — ресурс, описывающий операции над пользователем (сброс пароля, сброс 2FA, блокировка/разблокировка);
     • DexProviderCheck — ресурс, описывающий проверку доступности конкретного провайдера Dex. Проверка подтверждает, что провайдер существует, активен, Dex доступен, а эндпоинт провайдера достижим. При этом не выполняется полная процедура аутентификации пользователя.
   • удаление пользователей с истекшим сроком действия учетной записи (у которых значение поля status.expireAt раньше текущего времени);
   • периодическая проверка доступности настроенных внешних провайдеров аутентификации (используя кастомные ресурсы DexProviderCheck);
   • выявление конфликтующих настроек TLS-сертификатов в конфигурации подключения стороннего провайдера LDAP и экспорт соответствующей метрики.

   User-authn-controller при управлении кастомными ресурсами модуля использует в качестве бэкенда кастомные ресурсы Password, OfflineSession и Refreshtoken API-группы dex.coreos.com, используемые провайдером Dex как хранилище.

4. User-api — компонент, реализующий сервис сброса пользователем пароля своей учетной записи. Сервис доступен пользователю только через веб-интерфейс DKP и не требует прав администратора платформы. Сбросить можно пароль только для текущего пользователя. User-api валидирует токены поступающих запросов в dex. Для выполнения данной операции компонент создает кастомный ресурс UserOperation с типом ResetPassword, который обрабатывается компонентом user-authn-controller.

   Состоит из следующих контейнеров:

   • self-signed-generator — init-контейнер, генерирующий самоподписанный сертификат при запуске пода;
   • user-api — основной контейнер сервиса.

5. Basic-auth-proxy — опциональный компонент, состоящий из одного контейнера proxy, который запускается при включении базовой аутентификации в настройках одного из внешних провайдеров. При подключении к API Kubernetes компонент basic-auth-proxy выполняет базовую аутентификацию пользователей во внешних провайдерах через dex, кеширует результаты проверки учётных данных и проксирует аутентифицированные запросы в API Kubernetes.

Взаимодействия модуля

Модуль взаимодействует со следующими компонентами:

1. Внешние провайдеры аутентификации.

2. Kube-apiserver:

   • управление кастомными ресурсами модуля;
   • авторизация запросов на получение метрик.

С модулем взаимодействуют следующие внешние компоненты:

1. Ingress-контроллер — перенаправляет в dex-authenticator запросы на аутентификацию в служебных сервисах DP и в пользовательских приложениях.

2. Пользовательские приложения — могут аутентифицироваться в dex напрямую (без dex-authenticator), если для приложения настроен OAuth2-клиент в Dex. Подробнее с настройкой клиента Dex можно ознакомиться в документации модуля user-authn.

3. Kube-apiserver — обращается в dex при обработке запросов к API Kubernetes, выполняемых с использованием файла kubeconfig:

   • при запуске kube-apiserver запрашивает конфигурационный эндпоинт OIDC-провайдера (в данном случае — Dex), чтобы получить информацию об issuer и параметры для проверки токенов через JWKS-эндпоинт;
   • при получении запроса с ID token kube-apiserver проверяет его подпись с использованием ключей, полученных с JWKS-эндпоинта, а затем проверяет значения claim’ов токена на соответствие конфигурации сервера.

   Подробнее о том, как работает подключение к API Kubernetes с помощью сгенерированного kubeconfig, можно ознакомиться на соответствующей странице документации.

4. Prometheus-main — сбор метрик компонентов модуля.
5. Веб-интерфейс Deckhouse — пересылает запросы пользователей на сброс пароля.

Дополнительные ресурсы

• Документация модуля console
• Документация модуля user-authn