Configuring a GitLab identity provider - Configuring identity providers | Authentication and authorization

About identity providers in OKD
About GitLab authentication
Creating the secret
Creating a config map
Sample GitLab CR
Adding an identity provider to your cluster

Configure the gitlab identity provider using GitLab.com or any other GitLab instance as an identity provider.

About identity providers in OKD

By default, only a kubeadmin user exists on your cluster. To specify an identity provider, you must create a custom resource (CR) that describes that identity provider and add it to the cluster.

OKD user names containing /, :, and % are not supported.

About GitLab authentication

Configuring GitLab authentication allows users to log in to OKD with their GitLab credentials.

If you use GitLab version 7.7.0 to 11.0, you connect using the OAuth integration. If you use GitLab version 11.1 or later, you can use OpenID Connect (OIDC) to connect instead of OAuth.

Creating the secret

Identity providers use OKD secret objects in the openshift-config namespace to contain the client secret, client certificates, and keys.

Procedure

Create a secret object containing a string by using the following command:

$ oc create secret generic <secret_name> --from-literal=clientsecret=<secret> -n openshift-config

You can alternatively apply the following YAML to create the secret:

apiVersion: v1
kind: secret
metadata:
  name: <secret_name>
  namespace: openshift-config
type: Opaque
data:
  clientsecret: <base64_encoded_client_secret>

You can define a secret object containing the contents of a file by using the following command:
```
$ oc create secret generic <secret_name> --from-file=<path_to_file> -n openshift-config
```

Creating a config map

Identity providers use OKD ConfigMap objects in the openshift-config namespace to contain the certificate authority bundle. These are primarily used to contain certificate bundles needed by the identity provider.

Procedure

Define an OKD ConfigMap object containing the certificate authority by using the following command. The certificate authority must be stored in the ca.crt key of the ConfigMap object.

$ oc create configmap ca-config-map --from-file=ca.crt=/path/to/ca -n openshift-config

You can alternatively apply the following YAML to create the config map:

apiVersion: v1
kind: ConfigMap
metadata:
  name: ca-config-map
  namespace: openshift-config
data:
  ca.crt: |
    <CA_certificate_PEM>

Sample GitLab CR

The following custom resource (CR) shows the parameters and acceptable values for a GitLab identity provider.

GitLab CR

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: gitlabidp (1)
    mappingMethod: claim (2)
    type: GitLab
    gitlab:
      clientID: {...} (3)
      clientsecret: (4)
        name: gitlab-secret
      url: https://gitlab.com (5)
      ca: (6)
        name: ca-config-map

1	This provider name is prefixed to the GitLab numeric user ID to form an identity name. It is also used to build the callback URL.
2	Controls how mappings are established between this provider’s identities and `User` objects.
3	The client ID of a registered GitLab OAuth application. The application must be configured with a callback URL of `https://oauth-openshift.apps.<cluster-name>.<cluster-domain>/oauth2callback/<idp-provider-name>`.
4	Reference to an OKD `secret` object containing the client secret issued by GitLab.
5	The host URL of a GitLab provider. This could either be `https://gitlab.com/` or any other self hosted instance of GitLab.
6	Optional: Reference to an OKD `ConfigMap` object containing the PEM-encoded certificate authority bundle to use in validating server certificates for the configured URL.

Additional resources

See Identity provider parameters for information on parameters, such as mappingMethod, that are common to all identity providers.

Adding an identity provider to your cluster

After you install your cluster, add an identity provider to it so your users can authenticate.

Prerequisites

Create an OKD cluster.
Create the custom resource (CR) for your identity providers.
You must be logged in as an administrator.

Procedure

Apply the defined CR:

$ oc apply -f </path/to/CR>

If a CR does not exist, oc apply creates a new CR and might trigger the following warning: Warning: oc apply should be used on resources created by either oc create --save-config or oc apply. In this case you can safely ignore this warning.

Log in to the cluster as a user from your identity provider, entering the password when prompted.
```
$ oc login -u <username>
```
Confirm that the user logged in successfully, and display the user name.
```
$ oc whoami
```