Dex

Dex as the OIDC provider. Dex has no roles: the control plane reads the groups claim instead, so the users who may operate the factory are members of the group board-member. Dex passes the groups on from its connector (for example LDAP or an upstream OIDC provider). How the login works and every control plane setting: Authentication.

1. Register the client

Add a static client to the Dex configuration:

staticClients:
  - id: dark-factory
    name: Dark Factory
    secret: <client secret>
    redirectURIs:
      - https://factory.example.org/auth/callback
    postLogoutRedirectURIs:
      - https://factory.example.org/

Store the same secret in the instance namespace:

kubectl -n dark-factory create secret generic dark-factory-oidc \
  --from-literal=client-secret='<client secret>'

2. Provide the group

The ID token must contain "groups": ["board-member", …]. Where the group comes from depends on the connector:

The group name must be exactly board-member: the control plane compares the claim values as strings. The GitHub connector names every team group <org>:<team> (for example acme:board-member), so it cannot provide the group; use Keycloak or another connector instead.

3. Configure the control plane

Dex returns groups only for the scope groups, and a refresh token only for offline_access. Without a refresh token the session ends when the ID token expires.

oidc:
  issuerUrl: https://dex.example.org/dex
  clientId: dark-factory
  existingSecret: dark-factory-oidc
  clientSecretKey: client-secret
  publicUrl: https://factory.example.org
  rolesClaim: groups
  extraScopes: [groups, offline_access]

issuerUrl must match the issuer of the Dex configuration exactly, including the path. Then check the login as in Verify.

The local development setup (just serve-local, dev/dex.yaml) uses the same settings with static users (development guide).

Troubleshooting