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

title: Configure the Pinniped Supervisor to use GitLab as an OIDC provider description: Set up the Pinniped Supervisor to use GitLab login. cascade: layout: docs menu: docs: name: With GitLab OIDC weight: 90 parent: howto-configure-supervisor aliases: /docs/howto/configure-supervisor-with-gitlab/ 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 their GitLab credentials. This how-to guide assumes that you have already with working ingress, and that you have . Follow the instructions for and create a user, group, or instance-wide application. For example, to create a user-owned application: In GitLab, navigate to Create a new application: Enter a name for your application, such as "My Kubernetes Clusters". Enter the redirect URI. This is the `spec.issuer` you configured in your `FederationDomain` appended with `/callback`. Check the box saying that the application is Confidential. This is required and will cause GitLab to autogenerate a client ID and client secret for your application. Check the box saying to Expire Access Tokens to cause refresh tokens to be returned to the Supervisor. Select scope `openid`. This is required to get ID tokens. Also, this provides access to the `nickname` (GitLab username) and `groups` (GitLab groups) claims in the ID tokens. Optionally select other scopes which might provide access to other claims that you might want to use to determine the usernames of your users, for example `email`. Save the application and make note of the Application ID and Secret. Create an in the same namespace as the Supervisor. For example, this OIDCIdentityProvider and corresponding Secret for use the `nickname` claim (GitLab username) as the Kubernetes username: ```yaml apiVersion: idp.supervisor.pinniped.dev/v1alpha1 kind: OIDCIdentityProvider metadata: namespace: pinniped-supervisor name: gitlab spec: issuer: https://gitlab.com authorizationConfig: additionalScopes: [openid] allowPasswordGrant: false claims: username: nickname groups: groups client: secretName: gitlab-client-credentials apiVersion: v1 kind: Secret metadata: namespace: pinniped-supervisor name: gitlab-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-gitlab` over `my-idp`. Once your OIDCIdentityProvider has been created, you can validate your configuration by running: ```shell kubectl describe OIDCIdentityProvider -n pinniped-supervisor gitlab ``` Look at the `status` field. If it was configured correctly, you should see `phase: Ready`. You can also use other GitLab claims as the username. To do this, make sure you have configured the appropriate scopes on your GitLab application, such as `email`. You must also adjust the `spec.authorizationConfig` to request those scopes at login and adjust `spec.claims` to use those claims in Kubernetes, for example: ```yaml spec: authorizationConfig: additionalScopes: [ email ] claims: username: email groups: groups ``` To use privately hosted instance of GitLab, you can change the `spec.issuer` and `spec.tls.certificateAuthorityData` fields, for example: ```yaml apiVersion: idp.supervisor.pinniped.dev/v1alpha1 kind: OIDCIdentityProvider spec: issuer: https://gitlab.your-company.example.com. tls: certificateAuthorityData: "<gitlab-ca-bundle>" ``` Next, ! Then you'll be able to log into those clusters as any of the users from the GitLab directory.