OpenID Connect (OIDC) Introduction
An introduction to OpenID Connect (OIDC) Authentication in Kubernetes
All Kubernetes clusters have two categories of users: service accounts and normal users. Kubernetes manages authentication for service accounts, but the cluster administrator, or a separate service, manages authentication for normal users.
Kommander configures the cluster to use OpenID Connect (OIDC), a popular and extensible user authentication method, and installs Dex, a popular, open-source software product that integrates your existing Identity Providers with Kubernetes.
To begin, set up an Identity Provider with Dex, then use OIDC as the Authentication method.
Identity Provider
An Identity Provider (IdP) is a service that lets you manage identity information for users, including groups. A cluster created in Kommander uses Dex as its IdP. Dex, in turn, delegates to one or more external IdPs.
If you use already use one or more of the following IdPs, you can configure Dex to use them:
Name | Supports Refresh Tokens | Supports Groups Claim | Supports | Status | Notes |
---|---|---|---|---|---|
yes | yes | yes | stable | ||
yes | yes | yes | stable | ||
no | yes | no | stable | ||
yes | yes | yes | beta | ||
yes | yes | yes | beta | Includes Salesforce, Azure, etc. | |
yes | yes | yes | alpha | ||
yes | no | no | beta | ||
yes | yes | no | beta | ||
no | no | no | alpha | Authentication proxies such as Apache2 mod_auth, etc. | |
yes | yes | no | alpha | ||
no | yes | no | stable |
NOTE: These are the Identity Providers supported by Dex 2.22.0, the version used by DKP.
Add Login Connectors
Kommander uses Dex to provide OpenID Connect single sign-on (SSO) to the cluster. Dex can be configured to use multiple connectors, including GitHub, LDAP, and SAML 2.0. The Dex Connector documentation describes how to configure different connectors. You can add the configuration as the values field in the Dex application. An example Dex configuration provided to the Kommander CLI’s install
command would look similar to this:
apiVersion: config.kommander.mesosphere.io/v1alpha1
kind: Installation
apps:
dex:
values: |
config:
connectors:
- type: oidc
id: google
name: Google
config:
issuer: https://accounts.google.com/o/oauth2/v2/auth
clientID: YOUR_CLIENT_ID
clientSecret: YOUR_CLIENT_SECRET
redirectURI: https://DKP_CLUSTER_DOMAIN/dex/callback
scopes:
- openid
- profile
- email
insecureSkipEmailVerified: true
insecureEnableGroups: true
userIDKey: email
userNameKey: email
[...]
Change the Access Token Lifetime
By default, the client access token lifetime is 24 hours. After this time, the token expires and cannot be used to authenticate. See the Dex documentation for more information on access token expiration and rotation settings.
Here is an example configuration for extending the token lifetime to 48 hours:
apiVersion: config.kommander.mesosphere.io/v1alpha1
kind: Installation
apps:
dex:
values: |
config:
expiry:
idTokens: "48h"
[...]
Authentication
OpenID Connect is an extension of the OAuth2 authentication protocol. As required by OAuth2, the client must be registered with Dex. Do this by passing the name of the application and a callback/redirect URI. These handle the processing of the OpenID token after the user authenticates successfully. After registration, Dex returns a client_id
and a secret
. Authentication requests use these between the client and Dex to identify the client.
Users access Kommander in two ways:
To interact with Kubernetes API, usually through
kubectl
.To interact with the DKP UI, which has GUI dashboards for Prometheus, Grafana, etc.
In Kommander, Dex comes pre-configured with a client for these access use cases. The clients talk to Dex for authentication. Dex talks to the configured Identity Provider, or IdP, (for example LDAP, SAML, etc) to perform the actual task of authenticating the user.
If the user authenticates successfully, Dex pulls the user’s information from the IdP and forms an OpenID token. The token contains this information and returns it to the respective client’s callback URL. The client or end user uses this token for communicating with the DKP UI or Kubernetes API respectively.
This figure illustrates these components and their interaction at a high level: