7.3. Configuration d'un fournisseur d'identité LDAP


Configurer le fournisseur d'identité ldap pour valider les noms d'utilisateur et les mots de passe par rapport à un serveur LDAPv3, en utilisant l'authentification par liaison simple.

7.3.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.3.2. À propos de l'authentification LDAP

Lors de l'authentification, l'annuaire LDAP est parcouru à la recherche d'une entrée correspondant au nom d'utilisateur fourni. Si une correspondance unique est trouvée, une liaison simple est tentée en utilisant le nom distinctif (DN) de l'entrée et le mot de passe fourni.

Telles sont les mesures prises :

  1. Générer un filtre de recherche en combinant l'attribut et le filtre dans le site url configuré avec le nom d'utilisateur fourni par l'utilisateur.
  2. Effectuez une recherche dans le répertoire à l'aide du filtre généré. Si la recherche ne renvoie pas exactement une entrée, l'accès est refusé.
  3. Tentative de connexion au serveur LDAP à l'aide du DN de l'entrée récupérée lors de la recherche et du mot de passe fourni par l'utilisateur.
  4. Si la liaison n'aboutit pas, l'accès est refusé.
  5. Si la liaison est réussie, créez une identité en utilisant les attributs configurés comme identité, adresse électronique, nom d'affichage et nom d'utilisateur préféré.

L'adresse url configurée est une URL RFC 2255, qui spécifie l'hôte LDAP et les paramètres de recherche à utiliser. La syntaxe de l'URL est la suivante :

ldap://host:port/basedn?attribute?scope?filter

Pour cette URL :

Composant URLDescription

ldap

Pour le LDAP normal, utilisez la chaîne ldap. Pour LDAP sécurisé (LDAPS), utilisez plutôt ldaps.

host:port

Le nom et le port du serveur LDAP. La valeur par défaut est localhost:389 pour ldap et localhost:636 pour LDAPS.

basedn

Le DN de la branche du répertoire à partir de laquelle toutes les recherches doivent commencer. Au minimum, il doit s'agir du sommet de l'arborescence de votre répertoire, mais il peut également s'agir d'une sous-arborescence du répertoire.

attribute

L'attribut à rechercher. Bien que la RFC 2255 autorise une liste d'attributs séparés par des virgules, seul le premier attribut sera utilisé, quel que soit le nombre d'attributs fournis. Si aucun attribut n'est fourni, la valeur par défaut est uid. Il est recommandé de choisir un attribut qui sera unique pour toutes les entrées du sous-arbre que vous utiliserez.

scope

L'étendue de la recherche. Il peut s'agir de one ou sub. Si l'étendue n'est pas fournie, l'étendue par défaut est sub.

filter

Un filtre de recherche LDAP valide. S'il n'est pas fourni, la valeur par défaut est (objectClass=*)

Lors des recherches, l'attribut, le filtre et le nom d'utilisateur fourni sont combinés pour créer un filtre de recherche qui se présente comme suit :

(&(<filtre>)(<attribut>=<nom d'utilisateur>)))

Prenons l'exemple d'une URL de :

ldap://ldap.example.com/o=Acme?cn?sub?(enabled=true)

Lorsqu'un client tente de se connecter en utilisant le nom d'utilisateur bob, le filtre de recherche résultant sera (&(enabled=true)(cn=bob)).

Si l'annuaire LDAP nécessite une authentification pour la recherche, indiquez un bindDN et un bindPassword à utiliser pour effectuer la recherche d'entrée.

7.3.3. Création du secret LDAP

Pour utiliser le fournisseur d'identité, vous devez définir un objet OpenShift Container Platform Secret qui contient le champ bindPassword.

Procédure

  • Créez un objet Secret qui contient le champ bindPassword:

    $ oc create secret generic ldap-secret --from-literal=bindPassword=<secret> -n openshift-config 1
    1
    La clé secrète contenant le mot de passe de liaison pour l'argument --from-literal doit être appelée bindPassword.
    Astuce

    Vous pouvez également appliquer le code YAML suivant pour créer le secret :

    apiVersion: v1
    kind: Secret
    metadata:
      name: ldap-secret
      namespace: openshift-config
    type: Opaque
    data:
      bindPassword: <base64_encoded_bind_password>

7.3.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.3.5. Exemple de CR LDAP

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

LDAP CR

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: ldapidp 1
    mappingMethod: claim 2
    type: LDAP
    ldap:
      attributes:
        id: 3
        - dn
        email: 4
        - mail
        name: 5
        - cn
        preferredUsername: 6
        - uid
      bindDN: "" 7
      bindPassword: 8
        name: ldap-secret
      ca: 9
        name: ca-config-map
      insecure: false 10
      url: "ldaps://ldaps.example.com/ou=users,dc=acme,dc=com?uid" 11

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
Liste des attributs à utiliser comme identité. Le premier attribut non vide est utilisé. Au moins un attribut est requis. Si aucun des attributs énumérés n'a de valeur, l'authentification échoue. Les attributs définis sont récupérés sous forme brute, ce qui permet d'utiliser des valeurs binaires.
4
Liste des attributs à utiliser comme adresse électronique. Le premier attribut non vide est utilisé.
5
Liste des attributs à utiliser comme nom d'affichage. Le premier attribut non vide est utilisé.
6
Liste d'attributs à utiliser comme nom d'utilisateur préféré lors du provisionnement d'un utilisateur pour cette identité. Le premier attribut non vide est utilisé.
7
DN facultatif à utiliser pour se lier pendant la phase de recherche. Doit être défini si bindPassword est défini.
8
Référence optionnelle à un objet OpenShift Container Platform Secret contenant le mot de passe de liaison. Doit être défini si bindDN est défini.
9
Facultatif : Référence à un objet OpenShift Container Platform ConfigMap contenant le paquet d'autorité de certification codé PEM à utiliser dans la validation des certificats de serveur pour l'URL configurée. Utilisé uniquement lorsque insecure est false.
10
Lorsque true, aucune connexion TLS n'est établie avec le serveur. Lorsque false, les URL ldaps:// se connectent en utilisant TLS, et les URL ldap:// sont mis à niveau vers TLS. Ce paramètre doit être défini sur false lorsque les URL ldaps:// sont utilisées, car ces URL tentent toujours de se connecter à l'aide de TLS.
11
URL RFC 2255 qui spécifie l'hôte LDAP et les paramètres de recherche à utiliser.
Note

Pour établir une liste blanche d'utilisateurs pour une intégration LDAP, utilisez la méthode de mappage lookup. Avant d'autoriser une connexion à partir de LDAP, un administrateur de cluster doit créer un objet Identity et un objet User pour chaque utilisateur LDAP.

Ressources complémentaires

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