Подсистема IAM

В данном подразделе описывается архитектура подсистемы IAM (Identity and Access Management, идентификация и управление доступом) платформы Deckhouse Kubernetes Platform (DKP).

Подсистема IAM отвечает за следующие функции в DKP:

• аутентификация пользователей;
• ролевая модель управления доступом (RBAC);
• мультитенантность;
• автоматическое назначение аннотаций и лейблов неймспейсам.

В подсистему IAM входят следующие модули, реализующие описанные выше функции:

• user-authn — аутентификация пользователей;
• user-authz — ролевая модель управления доступом;
• multitenancy-manager — мультитенантность;
• namespace-configurator — автоматическое назначение аннотаций и лейблов неймспейсам.

1. Инициализация. До запуска kube-apiserver он запрашивает конфигурационный эндпоинт OIDC-провайдера (в данном случае — Dex), чтобы получить информацию об issuer и параметры для валидации токенов через JWKS-эндпоинт.
2. Генерация kubeconfig. Веб-интерфейс Deckhouse Kubernetes Platform (DKP) формирует kubeconfig, в котором сохраняются ID token и refresh token. Этот файл используется утилитой kubectl или другими клиентами Kubernetes.
3. Аутентификация при обращении к API. При получении запроса с ID token, kube-apiserver проверяет его подпись, используя ключи, полученные с JWKS-эндпоинта. Затем проверяются значения claim’ов iss (issuer) и aud (audience) токена на соответствие конфигурации сервера.

Одному пользователю разрешено только 20 попыток входа. Если указанный лимит израсходован, одна дополнительная попытка будет добавляться каждые 6 секунд.

1. Процесс входа через Dex. В большинстве случаев Dex перенаправляет пользователя на страницу входа внешнего провайдера (например, GitHub, Okta, Keycloak) и ожидает, что после успешной аутентификации пользователь будет возвращён на адрес /callback. Однако для провайдеров, таких как LDAP или Atlassian Crowd, этот механизм не работает. В таких случаях пользователь вводит логин и пароль в форму Dex, и сам Dex выполняет проверку через API соответствующего провайдера.
2. Хранение токенов и сессий. DexAuthenticator устанавливает cookie с полным refresh token, а не выдает короткоживущий ticket, как это делается с ID token. Это связано с тем, что Redis, используемый в DexAuthenticator, не сохраняет данные на диск. Если в Redis не найден ID token по ticket, пользователь может получить новый ID token, предъявив refresh token, сохранённый в cookie.
3. Передача токена в приложение. DexAuthenticator добавляет HTTP-заголовок Authorization с ID token из Redis. Это поведение может быть необязательным для некоторых приложений, таких как Upmeter, где механизмы авторизации реализованы иначе. Однако для приложений вроде Kubernetes Dashboard это обязательное поведение, так как Dashboard использует ID token для доступа к Kubernetes API от имени пользователя.

DKP использует модифицированную версию Dex для поддержки:

• групп для статических учетных записей пользователей и провайдера Bitbucket Cloud (параметр bitbucketCloud);
• передачи параметра group клиентам;
• механизма obsolete tokens, который позволяет избежать состояния гонки при продлении токена OIDC-клиентом.

DKP поддерживает режим высокой доступности highAvailability. При его включении аутентификаторы, отвечающие на auth request-запросы, развертываются с учетом требуемой избыточности для обеспечения непрерывной работы. В случае отказа любого из экземпляров аутентификаторов пользовательские аутентификационные сессии не прерываются.

Для создания проекта используются следующие кастомные ресурсы:

• ProjectTemplate — описывает шаблон проекта. Задается список ресурсов, которые будут созданы в проекте, а также схема параметров, которые можно передать при создании проекта;
• Project — описывает конкретный проект.

При создании Project из определенного ProjectTemplate происходит следующее:

1. Переданные параметры валидируются по OpenAPI-спецификации (параметр openAPIV3Schema ресурса ProjectTemplate).
2. Выполняется рендеринг шаблона для ресурсов с помощью Helm. Значения для рендеринга берутся из параметра parameters ресурса Project.
3. Создаётся неймспейс с именем, которое совпадает c именем Project.
4. По очереди создаются все ресурсы, описанные в шаблоне.

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

Для управления уровнем изоляции проекта можно использовать возможности Kubernetes, например:

• Ресурсы контроля доступа (AuthorizationRule / RoleBinding) — позволяют управлять взаимодействием объектов внутри неймспейса. С их помощью можно задавать правила и назначать роли, чтобы точно контролировать, кто и что может делать в проекте.
• Ресурсы контроля использования нагрузки (ResourceQuota) — с их помощью можно задать лимиты на использование процессорного времени (CPU), оперативной памяти (RAM), а также количества объектов внутри неймспейса. Это помогает избежать чрезмерной нагрузки и обеспечивает мониторинг за приложениями в рамках проекта.
• Ресурсы контроля сетевой связности (NetworkPolicy) — управляют входящим и исходящим сетевым трафиком в неймспейсе. Таким образом, можно настроить разрешенные подключения между подами, улучшить безопасность и управляемость сетевого взаимодействия в рамках проекта.

Эти инструменты можно комбинировать, чтобы настроить проект в соответствии с требованиями вашего приложения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Внешние провайдеры аутентификации.
2. Kube-apiserver — авторизация запросов на получение метрик.

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

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

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-эндпоинта.

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

4. Prometheus-main — сбор метрик провайдера dex.