Как работает подключение к Kubernetes API с помощью сгенерированного kubeconfig

Схема взаимодействия при подключении к Kubernetes API с помощью сгенерированного kubeconfig

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

  2. Генерация kubeconfig. Веб-интерфейс DKP формирует kubeconfig, в котором сохраняются ID token и refresh token. Этот файл используется утилитой kubectl или другими клиентами Kubernetes.

  3. Аутентификация при обращении к API. При получении запроса с ID token, kube-apiserver проверяет его подпись, используя ключи, полученные с JWKS-эндпоинта. Затем он сравнивает значения claim’ов iss (issuer) и aud (audience) токена с соответствующими значениями, указанными в своей конфигурации.

Как Dex защищен от подбора логина и пароля

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

Как работает аутентификация с помощью DexAuthenticator

Как работает аутентификация с помощью DexAuthenticator

  1. Процесс входа через Dex. В большинстве случаев Dex перенаправляет пользователя на страницу входа внешнего провайдера (например, GitHub, Okta, Keycloak) и ожидает, что после успешной аутентификации пользователь будет возвращён на адрес /callback. Однако для провайдеров, таких как LDAP или Atlassian Crowd, этот механизм не работает. В таких случаях пользователь вводит логин и пароль в форму Dex, и сам Dex выполняет проверку через API соответствующего провайдера.

  2. Хранение токенов и сессий. DexAuthenticator устанавливает cookie с полным refresh token, а не выдает короткоживущий тикет, как это делается с ID token. Это связано с тем, что Redis, используемый в DexAuthenticator, не сохраняет данные на диск. Если в Redis не найден ID token по тикету, пользователь может получить новый ID token, предъявив refresh token, сохранённый в cookie.

  3. Передача токена в приложение. DexAuthenticator добавляет HTTP-заголовок Authorization с ID token из Redis. Это поведение может быть необязательным для некоторых приложений, таких как Upmeter, где механизмы авторизации реализованы иначе. Однако для приложений вроде Kubernetes Dashboard это обязательное поведение, так как Dashboard использует ID token для доступа к Kubernetes API от имени пользователя.

Расширения от Фланта

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

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

Отказоустойчивый режим

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