7.7. Configuration d'un fournisseur d'identité GitLab
Configurer le fournisseur d'identité gitlab en utilisant GitLab.com ou toute autre instance de GitLab comme fournisseur d'identité.
7.7.1. À propos des fournisseurs d'identité dans OpenShift Container Platform
Par défaut, seul un utilisateur kubeadmin existe sur votre cluster. Pour spécifier un fournisseur d'identité, vous devez créer une ressource personnalisée (CR) qui décrit ce fournisseur d'identité et l'ajouter au cluster.
Les noms d'utilisateur OpenShift Container Platform contenant /, :, et % ne sont pas pris en charge.
7.7.2. À propos de l'authentification GitLab
La configuration de l'authentification GitLab permet aux utilisateurs de se connecter à OpenShift Container Platform avec leurs identifiants GitLab.
Si vous utilisez GitLab version 7.7.0 à 11.0, vous vous connectez en utilisant l'intégration OAuth. Si vous utilisez GitLab version 11.1 ou ultérieure, vous pouvez utiliser OpenID Connect (OIDC) pour vous connecter au lieu d'OAuth.
7.7.3. Création du secret
Les fournisseurs d'identité utilisent des objets OpenShift Container Platform Secret dans l'espace de noms openshift-config pour contenir le secret du client, les certificats du client et les clés.
Procédure
Créez un objet
Secretcontenant une chaîne de caractères à l'aide de la commande suivante :$ oc create secret generic <secret_name> --from-literal=clientSecret=<secret> -n openshift-config
AstuceVous pouvez également appliquer le code YAML suivant pour créer le secret :
apiVersion: v1 kind: Secret metadata: name: <secret_name> namespace: openshift-config type: Opaque data: clientSecret: <base64_encoded_client_secret>
Vous pouvez définir un objet
Secretcontenant le contenu d'un fichier, tel qu'un fichier de certificat, à l'aide de la commande suivante :oc create secret generic <secret_name> --from-file=<path_to_file> -n openshift-config
7.7.4. Création d'une carte de configuration
Les fournisseurs d'identité utilisent les objets OpenShift Container Platform ConfigMap dans l'espace de noms openshift-config pour contenir le paquet de l'autorité de certification. Ces objets sont principalement utilisés pour contenir les paquets de certificats nécessaires au fournisseur d'identité.
Cette procédure n'est nécessaire que pour GitHub Enterprise.
Procédure
Définissez un objet OpenShift Container Platform
ConfigMapcontenant l'autorité de certification en utilisant la commande suivante. L'autorité de certification doit être stockée dans la cléca.crtde l'objetConfigMap.$ oc create configmap ca-config-map --from-file=ca.crt=/path/to/ca -n openshift-config
AstuceVous pouvez également appliquer le YAML suivant pour créer la carte de configuration :
apiVersion: v1 kind: ConfigMap metadata: name: ca-config-map namespace: openshift-config data: ca.crt: | <CA_certificate_PEM>
7.7.5. Exemple de CR GitLab
La ressource personnalisée (CR) suivante présente les paramètres et les valeurs acceptables pour un fournisseur d'identité GitLab.
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
- Ce nom de fournisseur est préfixé à l'identifiant numérique de l'utilisateur GitLab pour former un nom d'identité. Il est également utilisé pour construire l'URL de rappel.
- 2
- Contrôle la manière dont les correspondances sont établies entre les identités de ce fournisseur et les objets
User. - 3
- L'identifiant client d'une application GitLab OAuth enregistrée. L'application doit être configurée avec une URL de rappel de
https://oauth-openshift.apps.<cluster-name>.<cluster-domain>/oauth2callback/<idp-provider-name>. - 4
- Référence à un objet OpenShift Container Platform
Secretcontenant le secret client émis par GitLab. - 5
- L'URL de l'hôte d'un fournisseur de GitLab. Il peut s'agir de
https://gitlab.com/ou de toute autre instance auto-hébergée de GitLab. - 6
- Facultatif : Référence à un objet OpenShift Container Platform
ConfigMapcontenant le bundle de l'autorité de certification codé en PEM à utiliser pour valider les certificats du serveur pour l'URL configurée.
Ressources complémentaires
-
Voir Paramètres du fournisseur d'identité pour des informations sur les paramètres, tels que
mappingMethod, qui sont communs à tous les fournisseurs d'identité.
7.7.6. Ajouter un fournisseur d'identité à votre cluster
Après avoir installé votre cluster, ajoutez-y un fournisseur d'identité pour que vos utilisateurs puissent s'authentifier.
Conditions préalables
- Créer un cluster OpenShift Container Platform.
- Créez la ressource personnalisée (CR) pour vos fournisseurs d'identité.
- Vous devez être connecté en tant qu'administrateur.
Procédure
Appliquer le CR défini :
$ oc apply -f </path/to/CR>
NoteSi un CR n'existe pas,
oc applycrée un nouveau CR et peut déclencher l'avertissement suivant :Warning: oc apply should be used on resources created by either oc create --save-config or oc apply. Dans ce cas, vous pouvez ignorer cet avertissement.Connectez-vous au cluster en tant qu'utilisateur de votre fournisseur d'identité, en saisissant le mot de passe lorsque vous y êtes invité.
$ oc login -u <nom d'utilisateur>
Confirmez que l'utilisateur s'est connecté avec succès et affichez le nom de l'utilisateur.
$ oc whoami
