Единая идентичность в федеративных Kubernetes и AI-платформах

Современные AI-платформы давно переросли концепцию простого веб-приложения за одним экраном входа. Сегодня пользователь начинает работу в центральном портале, открывает защищенный набор данных, запускает Jupyter-ноутбук, где эти данные физически хранятся, и вызывает AI-ассистента, который, в свою очередь, обращается к сервисам в совершенно другом кластере. С точки зрения пользователя этот процесс ощущается как единое целое, но за кулисами происходит сложная магия: контекст пользователя пересекает границы плоскости управления (control-plane) и плоскости данных (data-plane) на каждом шаге. Именно здесь традиционные решения единого входа (SSO) часто перестают быть достаточными, создавая узкие места в безопасности, производительности и пользовательском опыте.

Стандартный SSO успешно аутентифицирует пользователя на «входе», но командам платформ, управляющим федеративными данными или AI-инфраструктурой через множество кластеров, требуется надежный способ переноса этого контекста в распределенные среды выполнения. При этом критически важно не передавать «сырые» токены каждому приложению, не ослаблять механизмы отзыва доступа и не заставлять каждый кластер заново реализовывать логику взаимодействия с провайдером идентичности. Эта проблема особенно актуальна для AI и Data-платформ, где вычислительные ресурсы и данные часто остаются географически или организационно близкими к месту их создания, хранения или правового регулирования.

В данной статье мы подробно разберем паттерн центрального шлюза идентичности (Central Identity Gateway), который позволяет пропугировать идентичность пользователя через федеративные плоскости данных. Этот подход, успешно примененный в NVIDIA для внутренних платформ разработчиков, охватывает кластеры Kubernetes в AWS и OCI. Он не только снижает количество повторных входов на 55%, но и создает фундамент для унифицированных платформенных оболочек, согласованного выхода из системы и AI-ассистентов, действующих с делегированной идентичностью пользователя.

01Где заканчивается SSO и начинается идентичность плоскости данных

Хотя детали реализации могут варьироваться в зависимости от организации, базовый дизайн применим к командам платформ, работающим с федеративными средами Kubernetes, мультиоблачными платформами данных, рабочими станциями машинного обучения, внутренними порталами разработчиков или стеками AI-приложений с множеством аутентифицированных инструментов. SSO дает пользователю одну точку входа, но федеративные платформы данных нуждаются в способе переноса идентичности в плоскости, где фактически выполняется работа.

Ноутбук в одном кластере, API каталога в другом и ассистент, вызывающий движок запросов в третьем, — все они требуют одного и того же ответа: Кто этот пользователь и что ему разрешено делать здесь? Без модели распространения идентичности возникают серьезные проблемы:

• Аутентификация плоскости управления автоматически не становится доверенной идентичностью плоскости данных.
• Передача «сырых» токенов расширяет зону воздействия учетных данных и затрудняет понимание того, кто и какой токен использует.
• Каждый шлюз плоскости данных может интегрироваться с провайдером идентичности по-разному, что приводит к несогласованным утверждениям (claims), поведению обновления токенов и записям аудита.
• Выход из системы (logout) и отзыв доступа могут не распространяться быстро на каждый кластер или плоскость выполнения.
• Новые приложения наследуют сложность интеграции идентичности, вместо того чтобы потреблять стандартный контракт платформы.

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

Проблемы распределенной владения сессиями

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

1. Сессии привязаны к месту создания. Токен, выданный одним шлюзом, неизвестен другому, поэтому пользователи аутентифицируются для каждого сервиса, а не для платформы в целом.
2. Выход из системы локален. Выход из одного инструмента может оставить активные сессии в других местах, создавая путаницу для пользователя и риски безопасности.
3. Обновление токенов не скоординировано. Каждый шлюз независимо согласовывает циклы обновления с провайдером идентичности, увеличивая нагрузку и создавая расхождения в состояниях сессий.
4. Контекст идентичности несогласован. Потоковые сервисы часто парсят токены по-разному или дублируют логику аутентификации.
5. Новые сервисы наследуют старую сложность. Добавление нового инструмента обычно означает повторную сборку той же интеграции аутентификации.

02Сравнение двух паттернов идентичности

Существует два основных способа структурирования идентичности в федеративной платформе. Первый — распределенное владение сессиями. В этой модели каждый шлюз сервиса владеет своим собственным потоком входа, хранилищем сессий, логикой обновления токенов и поведением выхода. Это сохраняет независимость каждого кластера, но означает, что состояние идентичности не перемещается плавно по всей платформе.

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

Ниже приведено сравнение подходов по ключевым параметрам:

• Опыт входа: При распределенной модели пользователи могут входить один раз для каждого инструмента или шлюза. При централизованной — один раз для всей сессии платформы.
• Поведение выхода: Локально для сервиса или кластера против платформенного выхода через одну запись сессии.
• Обновление токенов: Повторяется независимо каждым шлюзом против скоординированного обновления центральным шлюзом.
• Нагрузка на IdP: Масштабируется с количеством пользователей, инструментов и кластеров против масштабирования преимущественно с количеством активных пользователей.
• Нисходящая идентичность: Часто дублируется или несогласована против стандартизации через доверенные заголовки или утверждения.

03Паттерн центрального шлюза идентичности

Центральный шлюз идентичности берет на себя три основные ответственности:

1. Создание сессии: обработка потока авторизационного кода OIDC и создание платформенной сессии.
2. Проверка идентичности для каждого запроса: ответ на вопрос «кто этот пользователь?» для любого шлюза или доверенного сервиса.
3. Управление жизненным циклом сессии: координация обновления токенов и выхода из системы по всей платформе.

Региональные аутентификационные шлюзы остаются на месте. Они по-прежнему обеспечивают соблюдение политик на уровне кластера, защищают локальные сервисы и внедряют идентичность в запросы. Изменяется только то, где хранятся сессии.

Вместо хранения сессий внутри каждого регионального шлюза, центральный шлюз идентичности записывает каждую аутентифицированную сессию в общее хранилище, такое как Redis. Сессия ключуется по непрозрачному идентификатору сессии (session ID) и связана с безопасным cookie браузера (HTTP-only), ограниченным доменом платформы.

Поток запросов: Вход, Проверка, Выход

Паттерн имеет три основных потока:

1. Вход (Login)

Когда пользователь прибывает без действительной платформенной сессии, региональный шлюз перенаправляет браузер в центральный шлюз идентичности. Центральный шлюз запускает поток авторизационного кода OIDC против провайдера идентичности организации, обменивает авторизационный код на серверной стороне, сохраняет resulting сессию в Redis с определенным временем жизни (TTL) и устанавливает HTTP-only cookie сессии.

Это cookie сессии становится учетным данными пользователя платформы на протяжении всей сессии.

2. Проверка для каждого запроса (Per-request validation)

При последующих запросах региональный шлюз отправляет cookie сессии в эндпоинт /gateway/userinfo. Центральный шлюз идентичности выполняет поиск сессии и возвращает утверждения идентичности, такие как ID пользователя, email, группы, роли и метаданные сессии.

Региональный шлюз использует эти утверждения для внедрения доверенных заголовков идентичности. Потоковые сервисы читают заголовки и применяют локальную логику авторизации, если это необходимо. Это держит путь запроса легковесным. Обычный запрос не требует обмена OIDC или прямого вызова провайдера идентичности. Он требует только поиска сессии и доверенного вызова проверки от шлюза к шлюзу.

3. Обновление токенов и выход (Token refresh and logout)

Когда токен доступа приближается к истечению, центральный шлюз идентичности обновляет его, используя сохраненный токен обновления (refresh token), и обновляет запись сессии. Поскольку обновленное состояние записывается в общее хранилище, каждый региональный шлюз видит одно и то же состояние сессии.

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

04Что разработчики могут использовать повторно

Конкретная инфраструктура за реализацией NVIDIA является внутренней, но архитектурный паттерн переносим. Внешние команды платформ могут использовать следующие компоненты:

• Единый владелец сессии для платформы.
• Минимальный эндпоинт проверки, такой как /gateway/userinfo.
• Стейтлесс (stateless) региональные шлюзы, делегирующие проверку.
• Общее хранилище сессий с явными TTL.
• Стандартизированные утверждения идентичности или заголовки для нисходящих сервисов.
• Единый путь выхода, инвалидирующий общую сессию.
• Модель миграции, позволяющая перемещать один шлюз или сервис за раз.

Паттерн не требует проприетарного промежуточного ПО. Его можно реализовать с помощью стандартных библиотек OIDC, Redis или другого хранилища сессий с низкой задержкой, а также интеграций шлюзов, доступных в общих средах Kubernetes ingress или service mesh.

05Снижение нагрузки на вышестоящие системы идентичности

Одно из менее очевидных преимуществ централизованного владения сессиями — снижение нагрузки на вышестоящую инфраструктуру идентичности (IdP).

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

С центральным шлюзом идентичности провайдер идентичности вызывается один раз за вход. Региональные шлюзы проверяют данные через общее хранилище, а не повторяют поток OIDC. Обновление токенов координируется одной службой, а контекст авторизации может кэшироваться до истечения срока действия.

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

06Что это значит на практике

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

1. Ускорить разработку новых сервисов: Новые AI-инструменты или приложения могут подключаться к платформе, просто интегрируясь с эндпоинтом /gateway/userinfo, не реализуя сложную логику OIDC.
2. Улучшить безопасность: Централизованный контроль над сессиями позволяет мгновенно отзывать доступ ко всем сервисам платформы одновременно, а не ждать распространения состояния по каждому кластеру.
3. Оптимизировать ресурсы: Снижение нагрузки на провайдер идентичности (например, Azure AD, Okta, Keycloak) за счет исключения дублирующих вызовов обмена токенами.
4. Обеспечить единый пользовательский опыт: Пользователи больше не сталкиваются с «бесконечными» запросами на вход при переходе между инструментами, что повышает продуктивность и удовлетворенность.

Для команд, работающих с Kubernetes и AI в условиях ограниченного доступа к международным облачным сервисам из РФ, этот паттерн особенно актуален. Он позволяет использовать локальные решения для хранилища сессий (например, локально развернутый Redis) и провайдеры идентичности, совместимые с OIDC, обеспечивая при этом ту же степень безопасности и удобства, что и в глобальных облаках. Ключевым шагом будет внедрение стандартизированных заголовков идентичности в ingress-контроллеры (например, Nginx Ingress или Istio) и использование OPA (Open Policy Agent) для оценки политик на основе этих заголовков.

Источник: NVIDIA Developer ↗