If you configure authentication through OpenID Connect (OIDC), users log in to the loft interface via an OIDC single sign-on (SSO) provider, such as Okta, KeyCloak, or dex. In this case, you usually do not create user accounts in loft and manage them through the OIDC provider that delegates the correct authentication to external providers, such as Github, Google or Microsoft.
OpenID Connect allows users to authenticate using a third-party provider which is useful if organizations want to:
- provide self sign-up for their users
- mirror the team memberships of their users from another provider
- enforce security standards such as two factor authentication (2FA)
OpenID Connect authentication is a paid feature of loft, so please make sure this feature is enabled in your loft instance.
Setup Dex for Single Sign-On
If you do not already have an OIDC provider, such as dex, Okta or KeyCloak, this section will show you how to deploy dex to let your users authenticate through external OAuth providers, such as Github, Google or Microsoft.
- Others (LDAP, SAML, ...)
For an extensive GitHub dex configuration take a look at the official dex documentation.
In order to configure Github for dex, you'll have to create a new Github Application for dex and copy the client id and secret to a file called
After creating the
dex-values.yaml for your OAuth provider (see above), you can now install dex via helm:
Configure an OIDC Provider in loft
In order to configure an OIDC provider in loft, you'll have to edit loft config in the admin section in the loft UI. If you don't have an OIDC provider installed, check out the previous section for how to install dex.
An example configuration for an OIDC provider could look like this:
Save the config and you should be able to login via your preferred OIDC provider after a couple of minutes.
For each new user that logs into loft that has not yet logged into loft, loft will create a new user object.
You can also automatically assign users based on their ID Token groups to teams (see below), by configuring the Kubernetes Groups in a loft team.
Mirror Team Memberships
Instead of statically assigning users to a team, you can also define "Kubernetes Groups" as team members. This is an advantage if you are using OpenID Connect for authentication because your existing team structure can be easily reflected in loft without the need to manually replicate team memberships.
Example: Your organization is working with GitHub and has existing teams with different members and access permissions in GitHub. If you configure loft to use GitHub as OpenID Connect Auth Provider and you create the teams you want to give Kubernetes access in loft, you can define a group membership for the GitHub team name. The result of this is that all users who are part of the GitHub team will also become a member of the corresponding team in loft.
The screenshot below shows the group "analytics-team" being added as member of the Analytics Team.
Disable Password Auth
To disable password authentication, change the loft config:
loft as OIDC Provider
Loft can also act as an OIDC provider for other services, e.g. a self-hosted container registry using Harbor.
To configure loft to act as an OIDC provider you will have to edit the loft config under the admin section in the loft UI:
An example configuration for loft to act as an OIDC provider could look like this:
To configure loft as an OIDC provider somewhere else, you can fill out the following fields with:
- OIDC Provider Endpoint / Issuer: https://my-loft-instance.com/oidc
- OIDC Client ID: example
- OIDC Client Secret: MYCLIENTSECRET
- Group Claim Name: groups
- Available OIDC Scopes: offline_access,openid,groups,email,profile
With this configuration your loft users are able to authenticate in another application that supports OIDC based authentication like Kubernetes or Harbor.