4.7. Configuring a GitLab identity provider
Configure a gitlab
identity provider to use GitLab.com or any other GitLab instance as an identity provider. 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.
4.7.1. About identity providers in OpenShift Container Platform
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.
OpenShift Container Platform user names containing /
, :
, and %
are not supported.
4.7.2. Creating the secret
Identity providers use OpenShift Container Platform Secret
objects in the openshift-config
namespace to contain the client secret, client certificates, and keys.
You can define an OpenShift Container Platform
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 define an OpenShift Container Platform
Secret
object containing the contents of a file, such as a certificate file, by using the following command.$ oc create secret generic <secret_name> --from-file=/path/to/file -n openshift-config
4.7.3. Creating a config map
Identity providers use OpenShift Container Platform 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.
This procedure is only required for GitHub Enterprise.
Procedure
Define an OpenShift Container Platform
ConfigMap
object containing the certificate authority by using the following command. The certificate authority must be stored in theca.crt
key of theConfigMap
object.$ oc create configmap ca-config-map --from-file=ca.crt=/path/to/ca -n openshift-config
4.7.4. 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 OpenShift Container Platform
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 OpenShift Container Platform
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.
4.7.5. Adding an identity provider to your clusters
After you install your cluster, add an identity provider to it so your users can authenticate.
Prerequisites
- Create an OpenShift Container Platform 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