SupportConsoleDéveloppeursCommencer un essaiContact

7.9. Configuration d'un fournisseur d'identité OpenID Connect

Configurer le fournisseur d'identité oidc pour qu'il s'intègre à un fournisseur d'identité OpenID Connect à l'aide d'un flux de code d'autorisation.

7.9.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.9.2. À propos de l'authentification OpenID Connect

L'opérateur d'authentification dans OpenShift Container Platform exige que le fournisseur d'identité OpenID Connect configuré mette en œuvre la spécification OpenID Connect Discovery.

Note

ID Token et UserInfo ne sont pas pris en charge.

Par défaut, le champ d'application openid est demandé. Si nécessaire, des portées supplémentaires peuvent être spécifiées dans le champ extraScopes.

Les revendications sont lues à partir du JWT id_token renvoyé par le fournisseur d'identité OpenID et, si cela est spécifié, à partir du JSON renvoyé par l'URL UserInfo.

Au moins une revendication doit être configurée pour être utilisée comme identité de l'utilisateur. La revendication d'identité standard est sub.

Vous pouvez également indiquer les revendications à utiliser comme nom d'utilisateur, nom d'affichage et adresse électronique préférés de l'utilisateur. Si plusieurs revendications sont spécifiées, c'est la première dont la valeur n'est pas vide qui est utilisée. Le tableau suivant répertorie les revendications standard :

RéclamationDescription

sub

Abréviation de "subject identifier." L'identité à distance de l'utilisateur auprès de l'émetteur.

preferred_username

Le nom d'utilisateur préféré lors du provisionnement d'un utilisateur. Un nom abrégé sous lequel l'utilisateur souhaite être désigné, tel que janedoe. Typiquement une valeur correspondant au login ou au nom d'utilisateur de l'utilisateur dans le système d'authentification, comme le nom d'utilisateur ou l'email.

email

Adresse électronique.

name

Nom d'affichage.

Voir la documentation sur les réclamations OpenID pour plus d'informations.

Note

À moins que votre fournisseur d'identité OpenID Connect ne prenne en charge le flux d'octroi ROPC (resource owner password credentials), les utilisateurs doivent obtenir un jeton auprès de <namespace_route>/oauth/token/request pour l'utiliser avec les outils en ligne de commande.

7.9.3. Fournisseurs de l'OIDC soutenus

Les fournisseurs OpenID Connect (OIDC) suivants sont testés et pris en charge par OpenShift Container Platform :

  • Services de fédération Active Directory pour Windows Server

    Note

    Actuellement, il n'est pas possible d'utiliser Active Directory Federation Services for Windows Server avec OpenShift Container Platform lorsque des réclamations personnalisées sont utilisées.

  • GitLab
  • Google
  • Keycloak

  • Plate-forme d'identité Microsoft (Azure Active Directory v2.0)

    Note

    Actuellement, il n'est pas possible d'utiliser la plateforme d'identité Microsoft lorsque des noms de groupes doivent être synchronisés.

  • Okta
  • Identité de Ping
  • Red Hat Single Sign-On

7.9.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.9.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.9.6. Exemples de CR OpenID Connect

Les ressources personnalisées (CR) suivantes indiquent les paramètres et les valeurs acceptables pour un fournisseur d'identité OpenID Connect.

Si vous devez spécifier un paquet de certificats personnalisé, des champs d'application supplémentaires, des paramètres de demande d'autorisation supplémentaires ou une URL userInfo, utilisez le CR OpenID Connect complet.

Standard OpenID Connect CR

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: oidcidp 1
    mappingMethod: claim 2
    type: OpenID
    openID:
      clientID: ... 3
      clientSecret: 4
        name: idp-secret
      claims: 5
        preferredUsername:
        - preferred_username
        name:
        - name
        email:
        - email
        groups:
        - groups
      issuer: https://www.idp-issuer.com 6

1
Ce nom de fournisseur est préfixé à la valeur de la revendication d'identité pour former un nom d'identité. Il est également utilisé pour construire l'URL de redirection.
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 d'un client enregistré auprès du fournisseur OpenID. Le client doit être autorisé à rediriger vers https://oauth-openshift.apps.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name>.
4
Une référence à un objet OpenShift Container Platform Secret contenant le secret du client.
5
La liste des revendications à utiliser comme identité. La première revendication non vide est utilisée.
6
L'identifiant de l'émetteur décrit dans la spécification OpenID. Doit utiliser https sans composante de requête ou de fragment.

OpenID Connect CR complet

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: oidcidp
    mappingMethod: claim
    type: OpenID
    openID:
      clientID: ...
      clientSecret:
        name: idp-secret
      ca: 1
        name: ca-config-map
      extraScopes: 2
      - email
      - profile
      extraAuthorizeParameters: 3
        include_granted_scopes: "true"
      claims:
        preferredUsername: 4
        - preferred_username
        - email
        name: 5
        - nickname
        - given_name
        - name
        email: 6
        - custom_email_claim
        - email
        groups: 7
        - groups
      issuer: https://www.idp-issuer.com

1
Facultatif : Référence à une carte de configuration OpenShift Container Platform contenant le paquet d'autorité de certification encodé PEM à utiliser dans la validation des certificats de serveur pour l'URL configurée.
2
Facultatif : La liste des champs d'application à demander, en plus du champ d'application openid, lors de la demande de jeton d'autorisation.
3
Facultatif : Une liste de paramètres supplémentaires à ajouter à la demande de jeton d'autorisation.
4
La liste des revendications à utiliser comme nom d'utilisateur préféré lors du provisionnement d'un utilisateur pour cette identité. La première revendication non vide est utilisée.
5
La liste des revendications à utiliser comme nom d'affichage. La première revendication non vide est utilisée.
6
La liste des créances à utiliser comme adresse électronique. La première demande non vide est utilisée.
7
La liste des réclamations à utiliser pour synchroniser les groupes du fournisseur OpenID Connect à OpenShift Container Platform lors de la connexion de l'utilisateur. Le premier claim non vide est utilisé.

Ressources complémentaires

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

    Si votre fournisseur d'identité OpenID Connect prend en charge le flux d'attribution des identifiants ROPC (resource owner password credentials), vous pouvez vous connecter avec un nom d'utilisateur et un mot de passe. Il se peut que vous deviez prendre des mesures pour activer le flux d'octroi ROPC pour votre fournisseur d'identité.

    Une fois le fournisseur d'identité OIDC configuré dans OpenShift Container Platform, vous pouvez vous connecter à l'aide de la commande suivante, qui vous demande votre nom d'utilisateur et votre mot de passe : 

    $ oc login -u <identity_provider_username> --server=<api_server_url_and_port>

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

    $ oc whoami

7.9.8. Configuration des fournisseurs d'identité à l'aide de la console web

Configurez votre fournisseur d'identité (IDP) via la console web au lieu de l'interface CLI.

Conditions préalables

  • Vous devez être connecté à la console web en tant qu'administrateur de cluster.

Procédure

  1. Naviguez jusqu'à Administration Cluster Settings.
  2. Sous l'onglet Configuration, cliquez sur OAuth.
  3. Dans la section Identity Providers, sélectionnez votre fournisseur d'identité dans le menu déroulant Add.
Note

Vous pouvez spécifier plusieurs IDP via la console web sans écraser les IDP existants.

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.