Authentication

Connecting to Kubernetes API using a generated kubeconfig

1. Initialization. Before the kube-apiserver starts, it requests the configuration endpoint of the OIDC provider (in this case — Dex) to retrieve the issuer and JWKS endpoint settings for token validation.

2. Kubeconfig generation. The DKP web interface generates a kubeconfig file that includes an ID token and a refresh token. This file is used by kubectl or other Kubernetes clients.

3. Authentication when accessing the API. Upon receiving a request with an ID token, the kube-apiserver verifies the token’s signature using keys from the JWKS endpoint. It then compares the iss (issuer) and aud (audience) claims in the token against the configured values.

How Dex protects against credential brute-forcing

Each user is allowed a maximum of 20 login attempts. Once this limit is reached, an additional attempt is allowed every 6 seconds.

How authentication via DexAuthenticator works

1. Login process via Dex. In most cases, Dex redirects the user to the login page of an external identity provider (e.g., GitHub, Okta, Keycloak), then expects the user to return to the /callback URL after successful authentication.
   However, for providers like LDAP or Atlassian Crowd, this flow is not supported. Instead, the user enters their login and password in the Dex login form, and Dex performs authentication by calling the provider’s API directly.

2. Token and session storage. DexAuthenticator sets a cookie containing the full refresh token, rather than issuing a short-lived ticket as with the ID token.
   This is because Redis, used by DexAuthenticator, does not persist data to disk.
   If the ID token is missing from Redis, the user can obtain a new one using the refresh token stored in the cookie.

3. Passing the token to the application. DexAuthenticator sets the Authorization HTTP header with the ID token from Redis.
   This may be optional for some applications, such as Upmeter, where other authorization mechanisms are used.
   However, for applications like the Kubernetes Dashboard, this behavior is critical, as the Dashboard forwards the ID token to access the Kubernetes API on behalf of the user.

Flant extensions

Deckhouse Kubernetes Platform uses a modified version of Dex that supports:

• Groups for static user accounts and the Bitbucket Cloud provider (via the bitbucketCloud parameter).
• Passing the group claim to clients.
• The obsolete tokens mechanism, which helps prevent race conditions when refreshing tokens in OIDC clients.

High availability mode

DKP supports a high-availability mode via the highAvailability setting.
When enabled, multiple authenticator instances are deployed with redundancy to ensure continuous service.
If any of the authenticators fail, active user authentication sessions are preserved and remain uninterrupted.