SupportConsoleDéveloppeursCommencer un essaiContact

7.6. Configuration d'un fournisseur d'identité GitHub ou GitHub Enterprise

Configurez le fournisseur d'identité github pour valider les noms d'utilisateur et les mots de passe par rapport au serveur d'authentification OAuth de GitHub ou GitHub Enterprise. OAuth facilite l'échange de jetons entre OpenShift Container Platform et GitHub ou GitHub Enterprise.

Vous pouvez utiliser l'intégration GitHub pour vous connecter à GitHub ou à GitHub Enterprise. Pour les intégrations GitHub Enterprise, vous devez fournir le site hostname de votre instance et pouvez éventuellement fournir un paquet de certificats ca à utiliser dans les demandes adressées au serveur.

Note

Les étapes suivantes s'appliquent à la fois à GitHub et à GitHub Enterprise, sauf indication contraire.

7.6.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.

Note

Les noms d'utilisateur OpenShift Container Platform contenant /, :, et % ne sont pas pris en charge.

7.6.2. À propos de l'authentification GitHub

La configuration de l'authentification GitHub permet aux utilisateurs de se connecter à OpenShift Container Platform avec leurs identifiants GitHub. Pour empêcher toute personne possédant un identifiant GitHub de se connecter à votre cluster OpenShift Container Platform, vous pouvez restreindre l'accès aux seules personnes appartenant à des organisations GitHub spécifiques.

7.6.3. Enregistrer une application GitHub

Pour utiliser GitHub ou GitHub Enterprise comme fournisseur d'identité, vous devez enregistrer une application à utiliser.

Procédure

  1. Enregistrer une application sur GitHub :

  2. Saisissez un nom d'application, par exemple My OpenShift Install.
  3. Saisissez l'URL d'une page d'accueil, par exemple https://oauth-openshift.apps.<cluster-name>.<cluster-domain>.
  4. Optionnel : Saisissez une description de l'application.

  5. Entrez l'URL de rappel d'autorisation, où la fin de l'URL contient le fournisseur d'identité name: 

    https://oauth-openshift.apps.<cluster-name>.<cluster-domain>/oauth2callback/<idp-provider-name>

    Par exemple : 

    https://oauth-openshift.apps.openshift-cluster.example.com/oauth2callback/github
  6. Cliquez sur Register application. GitHub fournit un identifiant et un secret client. Vous avez besoin de ces valeurs pour terminer la configuration du fournisseur d'identité.

7.6.4. 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 Secret contenant 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
    Astuce

    Vous 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 Secret contenant 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.6.5. 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é.

Note

Cette procédure n'est nécessaire que pour GitHub Enterprise.

Procédure

  • Définissez un objet OpenShift Container Platform ConfigMap contenant l'autorité de certification en utilisant la commande suivante. L'autorité de certification doit être stockée dans la clé ca.crt de l'objet ConfigMap. 

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

    Vous 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.6.6. Exemple de CR GitHub

La ressource personnalisée (CR) suivante présente les paramètres et les valeurs acceptables pour un fournisseur d'identité GitHub.

GitHub CR

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: githubidp 1
    mappingMethod: claim 2
    type: GitHub
    github:
      ca: 3
        name: ca-config-map
      clientID: {...} 4
      clientSecret: 5
        name: github-secret
      hostname: ... 6
      organizations: 7
      - myorganization1
      - myorganization2
      teams: 8
      - myorganization1/team-a
      - myorganization2/team-b

1
Ce nom de fournisseur est préfixé à l'identifiant numérique de l'utilisateur GitHub 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
Facultatif : Référence à un objet OpenShift Container Platform ConfigMap contenant le paquet d'autorité de certification encodé PEM à utiliser dans la validation des certificats de serveur pour l'URL configurée. A utiliser uniquement dans GitHub Enterprise avec un certificat racine non publiquement fiable.
4
L'identifiant client d'une application GitHub 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>.
5
Référence à un objet OpenShift Container Platform Secret contenant le secret client émis par GitHub.
6
Pour GitHub Enterprise, vous devez fournir le nom d'hôte de votre instance, par exemple example.com. Cette valeur doit correspondre à la valeur hostname de GitHub Enterprise dans le fichier /setup/settings et ne peut pas inclure de numéro de port. Si cette valeur n'est pas définie, il faut définir teams ou organizations. Pour GitHub, omettez ce paramètre.
7
La liste des organisations. Le champ organizations ou teams doit être activé si le champ hostname ne l'est pas ou si mappingMethod est associé à lookup. Ne peut être utilisé en combinaison avec le champ teams.
8
La liste des équipes. Le champ teams ou organizations doit être activé si le champ hostname n'est pas activé ou si mappingMethod est remplacé par lookup. Ne peut être utilisé en combinaison avec le champ organizations.
Note

Si organizations ou teams est spécifié, seuls les utilisateurs de GitHub qui sont membres d'au moins une des organisations répertoriées seront autorisés à se connecter. Si l'application GitHub OAuth configurée dans clientID n'appartient pas à l'organisation, un propriétaire de l'organisation doit accorder un accès à un tiers pour utiliser cette option. Cela peut être fait lors de la première connexion à GitHub par l'administrateur de l'organisation, ou à partir des paramètres de l'organisation GitHub.

Ressources complémentaires

7.6.7. 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

  1. Appliquer le CR défini : 

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

    Si un CR n'existe pas, oc apply cré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.

  2. Obtenir un jeton du serveur OAuth.

    Tant que l'utilisateur kubeadmin a été supprimé, la commande oc login fournit des instructions sur la manière d'accéder à une page web où vous pouvez récupérer le jeton.

    Vous pouvez également accéder à cette page à partir de la console web en naviguant vers (?) Help Command Line Tools Copy Login Command.

  3. Se connecter au cluster en transmettant le jeton d'authentification. 

    $ oc login --token=<token>
    Note

    Ce fournisseur d'identité ne permet pas de se connecter avec un nom d'utilisateur et un mot de passe.

  4. Confirmez que l'utilisateur s'est connecté avec succès et affichez le nom de l'utilisateur. 

    $ oc whoami
Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.