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

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.

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.

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.

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

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

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.

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

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

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

Après avoir installé votre cluster, ajoutez-y un fournisseur d'identité pour que vos utilisateurs puissent s'authentifier.

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.

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

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

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

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

Failed responses