Модуль user-authn реализует единую систему аутентификации, интегрированную с Kubernetes и веб-интерфейсами, используемыми в модулях Deckhouse Kubernetes Platform (DKP), например, в модуле console.
Подробнее с настройками модуля и примерами его использования можно ознакомиться в соответствующем разделе документации.
Архитектура модуля
Для упрощения схемы приняты следующие допущения:
- На схеме показано, что контейнеры разных подов взаимодействуют друг с другом напрямую. Фактически они взаимодействуют через соответствующие сервисы Kubernetes (внутренние балансировщики). Названия сервисов не указываются, если они очевидны из контекста. В остальных случаях название сервиса указано над стрелкой.
- Поды могут быть запущены в нескольких репликах, однако на схеме все поды изображены в одной реплике.
В DKP для служебных сервисов и пользовательских приложений используются две схемы аутентификации:
- с использованием dex-authenticator;
- с использованием клиента Dex.
Архитектура модуля user-authn на уровне 2 модели C4 и его взаимодействия с другими компонентами DKP изображены на следующих диаграммах.
Вариант с использованием dex-authenticator:

Вариант с использованием клиента Dex (для упрощения на схеме не показано взаимодействие модуля prometheus-main с dex):

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

Компоненты модуля
Модуль состоит из следующих компонентов:
-
Dex — федеративный провайдер OpenID Connect, поддерживающий работу со статическими пользователями и интеграцию с внешними провайдерами аутентификации, такими как SAML, GitLab или GitHub.
Состоит из следующих контейнеров:
- dex — основной контейнер, реализующий функции Dex;
- kube-rbac-proxy — сайдкар-контейнер с авторизующим прокси на основе Kubernetes RBAC для организации защищенного доступа к метрикам провайдера.
-
Dex-authenticator — middleware-сервис для аутентификации запросов к приложениям через сервис аутентификации кластера DKP.
При соответствующей настройке Ingress-контроллера (через модуль
auth_requestNGINX) запросы сначала направляются в dex-authenticator для аутентификации.Состоит из следующих контейнеров:
- dex-authenticator — основной контейнер сервиса;
- redis — сайдкар-контейнер c базой данных Redis, используемый для временного хранения ID Token и быстрого доступа к ним (за счет размещения базы в памяти);
- self-signed-generator — init-контейнер, генерирующий самоподписанный сертификат при запуске пода.
Взаимодействия модуля
Модуль взаимодействует со следующими компонентами:
- Внешние провайдеры аутентификации.
- Kube-apiserver — авторизация запросов на получение метрик.
С модулем взаимодействуют следующие внешние компоненты:
-
Ingress-контроллер — перенаправляет в dex-authenticator запросы на аутентификацию в служебных сервисах DKP и в пользовательских приложениях.
-
Пользовательские приложения — могут аутентифицироваться в dex напрямую (без dex-authenticator), если для приложения настроен OAuth2-клиент в Dex. Подробнее с настройкой клиента Dex можно ознакомиться в документации модуля
user-authn. -
Kube-apiserver — обращается в dex при обработке запросов к API Kubernetes, выполняемых с использованием файла kubeconfig:
- при запуске kube-apiserver запрашивает конфигурационный эндпоинт OIDC-провайдера (в данном случае — Dex), чтобы получить информацию об
issuerи параметры для проверки токенов через JWKS-эндпоинт; - при получении запроса с ID token kube-apiserver проверяет его подпись с использованием ключей, полученных с JWKS-эндпоинта.
Подробнее о тем, как работает подключение к API Kubernetes с помощью сгенерированного kubeconfig, можно ознакомиться на соответствующей странице документации.
- при запуске kube-apiserver запрашивает конфигурационный эндпоинт OIDC-провайдера (в данном случае — Dex), чтобы получить информацию об
-
Prometheus-main — сбор метрик провайдера dex.