Project: Pinniped (Provisioning / Key Management)
File: configure-supervisor-with-dex.md

title: Configure the Pinniped Supervisor to use Dex with Github as an OIDC provider description: Set up the Pinniped Supervisor to use Dex login. cascade: layout: docs menu: docs: name: With Dex OIDC weight: 80 parent: howto-configure-supervisor aliases: /docs/howto/configure-supervisor-with-dex/ The Supervisor is an issuer that supports connecting "upstream" identity providers to many "downstream" cluster clients. This guide shows you how to configure the Supervisor so that users can authenticate to their Kubernetes cluster using Dex and Github. This how-to guide assumes that you have already with working ingress, and that you have . You'd also have to have an instance of Dex up and running, i.e. accessible at `https://<dex-dns-record>`. You can refer to the guidelines for more information on how to deploy it. Dex is an OIDC issuer that supports various identity providers through connectors, i.e. LDAP, Github, Gitlab, Google, SAML and much more. Take a look at its to understand how to configure such connector in Dex. In this example, we'll show how to use Dex to identify users through their GitHub account. First, we need to go to your Github account settings and by populating the following rows - Application name - `Dex application` Homepage URL - `https://<dex-dns-record>` Authorization callback URL - `https://<dex-dns-record>/callback` // this is where Github will redirect you to once your app has authorized Once completed, copy your `Client ID` and `Client secret` (generate one if there's none) as those two will be needed to configure a Github connector in Dex. To setup one, edit the configuration used by Dex by adding the following - ```bash ... connectors: type: github id: github name: GitHub config: clientID: $GITHUBCLIENTID clientSecret: $GITHUBCLIENTSECRET redirectURI: https://<dex-dns-record>/callback ... ``` Follow the instructions for and create a static client application, in our case the client happens be the Supervisor. Note that the "openid" scope is always included, but you can always request additional scopes that you can then pass to your Kubernetes cluster, such as "groups" for example. To create a static client application, edit the configuration used by Dex (can be a file or a ConfigMap) by adding the following - ```bash ... staticClients: id: pinniped-supervisor secret: pinniped-supervisor-secret name: 'Pinniped Supervisor client' redirectURIs: 'http://<pinniped-supervisor-dns-record>/callback' ... ``` Create an resource in the same namespace as the Supervisor. For example, the following OIDCIdentityProvider and the corresponding Secret use Dex's `email` claim as the Kubernetes username: ```yaml apiVersion: idp.supervisor.pinniped.dev/v1alpha1 kind: OIDCIdentityProvider metadata: namespace: pinniped-supervisor name: dex spec: issuer: https://<dex-dns-record> authorizationConfig: additionalScopes: [offline_access, groups, email] allowPasswordGrant: false claims: username: email groups: groups client: secretName: dex-client-credentials apiVersion: v1 kind: Secret metadata: namespace: pinniped-supervisor name: dex-client-credentials type: secrets.pinniped.dev/oidc-client stringData: clientID: "<your-client-id>" clientSecret: "<your-client-secret>" ``` Note that the `metadata.name` of the OIDCIdentityProvider resource may be visible to end users at login prompts if you choose to enable `allowPasswordGrant`, so choose a name which will be understood by your end users. For example, if you work at Acme Corp, choose something like `acme-corporate-ldap` over `my-idp`. Once your OIDCIdentityProvider resource has been created, you can validate your configuration by running: ```bash kubectl describe OIDCIdentityProvider -n pinniped-supervisor dex ``` Look at the `status` field. If it was configured correctly, you should see `phase: Ready`. Now that you have configured the Supervisor to use Dex, you will want to .