SupportConsoleDéveloppeursCommencer un essaiContact

7.4. Configuration d'un fournisseur d'identité pour l'authentification de base

Configurer le fournisseur d'identité basic-authentication pour que les utilisateurs puissent se connecter à OpenShift Container Platform avec des informations d'identification validées par rapport à un fournisseur d'identité distant. L'authentification de base est un mécanisme d'intégration générique.

7.4.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.4.2. A propos de l'authentification de base

L'authentification de base est un mécanisme d'intégration générique qui permet aux utilisateurs de se connecter à OpenShift Container Platform avec des informations d'identification validées par un fournisseur d'identité distant.

L'authentification de base étant générique, vous pouvez utiliser ce fournisseur d'identité pour des configurations d'authentification avancées.

Important

L'authentification de base doit utiliser une connexion HTTPS avec le serveur distant afin d'éviter que l'identifiant et le mot de passe de l'utilisateur ne soient espionnés et que des attaques de type "man-in-the-middle" ne se produisent.

Lorsque l'authentification de base est configurée, les utilisateurs envoient leur nom d'utilisateur et leur mot de passe à OpenShift Container Platform, qui valide ensuite ces informations d'identification auprès d'un serveur distant en effectuant une requête de serveur à serveur, en transmettant les informations d'identification en tant qu'en-tête d'authentification de base. Les utilisateurs doivent donc envoyer leurs informations d'identification à OpenShift Container Platform lors de la connexion.

Note

Cela ne fonctionne que pour les mécanismes de connexion par nom d'utilisateur/mot de passe, et OpenShift Container Platform doit être en mesure de faire des demandes de réseau au serveur d'authentification distant.

Les noms d'utilisateur et les mots de passe sont validés par rapport à une URL distante qui est protégée par une authentification de base et renvoie du JSON.

Une réponse 401 indique que l'authentification a échoué.

Un état non200 ou la présence d'une clé "error" non vide indique une erreur : 

{"error":"Error message"}

Un statut 200 avec une clé sub (sujet) indique un succès : 

{\i1}"sub":\N-"userid" } 1
1
Le sujet doit être unique pour l'utilisateur authentifié et ne doit pas pouvoir être modifié.

Une réponse positive peut éventuellement fournir des données supplémentaires, telles que

  • Un nom d'affichage à l'aide de la touche name. Par exemple : 

    {"sub":"userid", "name": "User Name", ...}

  • Une adresse électronique à l'aide de la clé email. Par exemple : 

    {"sub":"userid", "email":"user@example.com", ...}

  • Un nom d'utilisateur préféré utilisant la clé preferred_username. Ceci est utile lorsque le sujet unique et immuable est une clé de base de données ou un UID, et qu'il existe un nom plus lisible par l'homme. Ceci est utilisé comme un indice lors du provisionnement de l'utilisateur OpenShift Container Platform pour l'identité authentifiée. Par exemple : 

    {"sub":"014fbff9a07c", "preferred_username":"bob", ...}

7.4.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 Secret contenant la clé et le certificat à l'aide de la commande suivante : 

    $ oc create secret tls <secret_name> --key=key.pem --cert=cert.pem -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: kubernetes.io/tls
data:
  tls.crt: <base64_encoded_cert>
  tls.key: <base64_encoded_key>

7.4.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é.

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.4.5. Exemple de CR d'authentification de base

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

Authentification de base CR

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: basicidp 1
    mappingMethod: claim 2
    type: BasicAuth
    basicAuth:
      url: https://www.example.com/remote-idp 3
      ca: 4
        name: ca-config-map
      tlsClientCert: 5
        name: client-cert-secret
      tlsClientKey: 6
        name: client-key-secret

1
Ce nom de fournisseur est préfixé à l'identifiant de l'utilisateur renvoyé pour former un nom d'identité.
2
Contrôle la manière dont les correspondances sont établies entre les identités de ce fournisseur et les objets User.
3
URL acceptant les informations d'identification dans les en-têtes d'authentification de base.
4
Facultatif : Référence à un objet OpenShift Container Platform ConfigMap contenant le bundle de l'autorité de certification codé en PEM à utiliser pour valider les certificats du serveur pour l'URL configurée.
5
Facultatif : Référence à un objet OpenShift Container Platform Secret contenant le certificat client à présenter lors des requêtes à l'URL configurée.
6
Référence à un objet OpenShift Container Platform Secret contenant la clé du certificat client. Requis si tlsClientCert est spécifié.

Ressources complémentaires

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

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

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

    $ oc whoami

7.4.7. Exemple de configuration Apache HTTPD pour les fournisseurs d'identité de base

La configuration de base du fournisseur d'identification (IDP) dans OpenShift Container Platform 4 exige que le serveur IDP réponde avec JSON pour les succès et les échecs. Vous pouvez utiliser un script CGI dans Apache HTTPD pour y parvenir. Cette section fournit des exemples.

Exemple /etc/httpd/conf.d/login.conf

<VirtualHost *:443>
  # CGI Scripts in here
  DocumentRoot /var/www/cgi-bin

  # SSL Directives
  SSLEngine on
  SSLCipherSuite PROFILE=SYSTEM
  SSLProxyCipherSuite PROFILE=SYSTEM
  SSLCertificateFile /etc/pki/tls/certs/localhost.crt
  SSLCertificateKeyFile /etc/pki/tls/private/localhost.key

  # Configure HTTPD to execute scripts
  ScriptAlias /basic /var/www/cgi-bin

  # Handles a failed login attempt
  ErrorDocument 401 /basic/fail.cgi

  # Handles authentication
  <Location /basic/login.cgi>
    AuthType Basic
    AuthName "Please Log In"
    AuthBasicProvider file
    AuthUserFile /etc/httpd/conf/passwords
    Require valid-user
  </Location>
</VirtualHost>

Exemple /var/www/cgi-bin/login.cgi

#!/bin/bash
echo "Content-Type: application/json"
echo ""
echo '{"sub":"userid", "name":"'$REMOTE_USER'"}'
exit 0

Exemple /var/www/cgi-bin/fail.cgi

#!/bin/bash
echo "Content-Type: application/json"
echo ""
echo '{"error": "Login failure"}'
exit 0

7.4.7.1. Exigences en matière de fichiers

Voici les conditions requises pour les fichiers que vous créez sur un serveur web Apache HTTPD :

  • login.cgi et fail.cgi doivent être exécutables (chmod x).
  • login.cgi et fail.cgi doivent avoir des contextes SELinux appropriés si SELinux est activé : restorecon -RFv /var/www/cgi-bin ou s'assurer que le contexte est httpd_sys_script_exec_t en utilisant ls -laZ.
  • login.cgi n'est exécuté que si l'utilisateur se connecte avec succès, conformément aux directives de Require and Auth.
  • fail.cgi est exécuté si l'utilisateur ne parvient pas à se connecter, ce qui entraîne une réponse HTTP 401.

7.4.8. Dépannage de l'authentification de base

Le problème le plus courant est lié à la connectivité réseau avec le serveur backend. Pour un débogage simple, exécutez les commandes curl sur le maître. Pour tester une connexion réussie, remplacez <user> et <password> dans l'exemple de commande suivant par des informations d'identification valides. Pour tester une connexion non valide, remplacez-les par de fausses informations d'identification. 

$ curl --cacert /path/to/ca.crt --cert /path/to/client.crt --key /path/to/client.key -u <user>:<password> -v https://www.example.com/remote-idp

Successful responses

Un statut 200 avec une clé sub (sujet) indique un succès : 

{"sub":"userid"}

Le sujet doit être unique pour l'utilisateur authentifié et ne doit pas pouvoir être modifié.

Une réponse positive peut éventuellement fournir des données supplémentaires, telles que

  • Un nom d'affichage à l'aide de la touche name: 

    {"sub":"userid", "name": "User Name", ...}

  • Une adresse électronique à l'aide de la touche email: 

    {"sub":"userid", "email":"user@example.com", ...}

  • Un nom d'utilisateur préféré à l'aide de la touche preferred_username: 

    {"sub":"014fbff9a07c", "preferred_username":"bob", ...}

    La clé preferred_username est utile lorsque le sujet unique et immuable est une clé de base de données ou un UID, et qu'il existe un nom plus lisible par l'homme. Elle est utilisée comme indice lors du provisionnement de l'utilisateur OpenShift Container Platform pour l'identité authentifiée.

Failed responses

  • Une réponse 401 indique que l'authentification a échoué.
  • Un état non200 ou la présence d'une clé "error" non vide indique une erreur : {"error":"Error message"}
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.