Аутентификация

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

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) токена на соответствие конфигурации сервера.

Защита Dex от подбора логина и пароля

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

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

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-запросы, развертываются с учетом требуемой избыточности для обеспечения непрерывной работы. В случае отказа любого из экземпляров аутентификаторов пользовательские аутентификационные сессии не прерываются.