2021-04-27 23:18:30 +00:00
---
2021-05-04 19:13:20 +00:00
title: Configure the Pinniped Supervisor to use GitLab as an OIDC Provider
description: Set up the Pinniped Supervisor to use GitLab login.
2021-04-27 23:18:30 +00:00
cascade:
layout: docs
menu:
docs:
2021-05-04 19:13:20 +00:00
name: Configure Supervisor With GitLab
2021-04-27 23:18:30 +00:00
weight: 35
parent: howtos
---
The Supervisor is an [OpenID Connect (OIDC) ](https://openid.net/connect/ ) issuer that supports connecting a single "upstream" OIDC identity provider to many "downstream" cluster clients.
2021-04-28 20:34:36 +00:00
This guide shows you how to configure the Supervisor so that users can authenticate to their Kubernetes
2021-05-04 19:13:20 +00:00
cluster using their GitLab credentials.
2021-04-27 23:18:30 +00:00
## Prerequisites
2021-05-04 19:13:20 +00:00
This how-to guide assumes that you have already [installed the Pinniped Supervisor ]({{< ref "install-supervisor" >}} ) with working ingress,
and that you have [configured a `FederationDomain` to issue tokens for your downstream clusters ]({{< ref "configure-supervisor" >}} ).
## Configuring your GitLab Application
Follow the instructions for [using GitLab as an OAuth2 authentication service provider ](https://docs.gitlab.com/ee/integration/oauth_provider.html ) and create a user, group, or instance-wide application.
2021-04-27 23:18:30 +00:00
2021-05-04 19:13:20 +00:00
For example, to create a user-owned application:
1. In GitLab, navigate to [_User Settings_ > _Applications_ ](https://gitlab.com/-/profile/applications )
2021-04-27 23:18:30 +00:00
1. Create a new application:
1. Enter the name of your application.
2021-05-04 19:13:20 +00:00
1. Enter the redirect URI. This is the `spec.issuer` you configured in your `FederationDomain` appended with `/callback` .
1. Check the box saying that the application is _Confidential_ .
2021-04-27 23:18:30 +00:00
1. Select scope `openid` . Optionally select `profile` and `email` .
2021-05-04 19:13:20 +00:00
1. Save the application and make note of the _Application ID_ and _Secret_ .
2021-04-27 23:18:30 +00:00
## Configuring the Supervisor cluster
2021-05-04 19:13:20 +00:00
2021-04-27 23:18:30 +00:00
Create an [`OIDCIdentityProvider` ](https://github.com/vmware-tanzu/pinniped/blob/main/generated/1.20/README.adoc#oidcidentityprovider ) in the same namespace as the Supervisor.
2021-05-04 19:13:20 +00:00
For example, here is an `OIDCIdentityProvider` that works against [gitlab.com ](https://gitlab.com ) and uses the GitLab `email` claim as the Kubernetes username:
2021-04-27 23:18:30 +00:00
```yaml
apiVersion: idp.supervisor.pinniped.dev/v1alpha1
kind: OIDCIdentityProvider
metadata:
2021-05-04 19:13:20 +00:00
namespace: pinniped-supervisor
name: gitlab
2021-04-27 23:18:30 +00:00
spec:
2021-05-04 19:13:20 +00:00
# Specify the upstream issuer name. This should be something like
# https://gitlab.com or https://gitlab.your-company.example.com.
issuer: https://gitlab.com
# Specify the CA bundle for the GitLab server as base64-encoded PEM
# data. This will only be needed for self-managed GitLab.
# tls:
# certificateAuthorityData: "< gitlab-ca-bundle > "
# Request any scopes other than "openid" that you selected when
# creating your GitLab application.
2021-04-27 23:18:30 +00:00
authorizationConfig:
additionalScopes: [ email, profile ]
2021-05-04 19:13:20 +00:00
# Specify how GitLab claims are mapped to Kubernetes identities.
2021-04-27 23:18:30 +00:00
claims:
2021-05-04 19:13:20 +00:00
# Specify the name of the claim in your GitLab token that will be mapped
# to the "username" claim in downstream tokens minted by the Supervisor.
2021-04-27 23:18:30 +00:00
# For example, "email" or "sub".
2021-05-04 19:13:20 +00:00
#
# See here for a full list of available claims:
# https://docs.gitlab.com/ee/integration/openid_connect_provider.html
username: email
# Specify the name of the claim in GitLab that represents the groups
# that the user belongs to. Note that GitLab's "groups" claim comes from
# their "/userinfo" endpoint, not the token.
groups: groups
# Specify the name of the Kubernetes Secret that contains your GitLab
# application's client credentials (created below).
2021-04-27 23:18:30 +00:00
client:
2021-05-04 19:13:20 +00:00
secretName: gitlab-client-credentials
2021-04-27 23:18:30 +00:00
```
2021-05-04 19:13:20 +00:00
Then, create a `Secret` containing the Client ID and Client Secret in the same namespace as the Supervisor:
2021-04-27 23:18:30 +00:00
```yaml
apiVersion: v1
kind: Secret
metadata:
2021-05-04 19:13:20 +00:00
namespace: pinniped-supervisor
name: gitlab-client-credentials
type: secrets.pinniped.dev/oidc-client
2021-04-27 23:18:30 +00:00
stringData:
2021-05-04 19:13:20 +00:00
# The "Application ID" that you got from GitLab.
clientID: "< your-client-id > "
# The "Secret" that you got from GitLab.
clientSecret: "< your-client-secret > "
2021-04-27 23:18:30 +00:00
```
2021-05-04 19:13:20 +00:00
To validate your configuration, run:
2021-04-28 20:34:36 +00:00
```shell
2021-05-04 19:13:20 +00:00
kubectl describe OIDCIdentityProvider gitlab
2021-04-28 20:34:36 +00:00
```
Look at the `status` field. If it was configured correctly, you should see `phase: Ready` .
2021-04-27 23:18:30 +00:00
## Next Steps
2021-05-04 19:13:20 +00:00
Now that you have configured the Supervisor to use GitLab, you may want to [configure the Concierge to validate JWTs issued by the Supervisor ]({{< ref "configure-concierge-jwt" >}} ).