7.5. Configuration d'un fournisseur d'identité d'en-tête de requête

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

1. Créez le certificat pour la configuration Apache. Le certificat que vous spécifiez comme valeur du paramètre SSLProxyMachineCertificateFile est le certificat client du proxy qui est utilisé pour authentifier le proxy auprès du serveur. Il doit utiliser TLS Web Client Authentication comme type de clé étendue.

2. Créez la configuration d'Apache. Utilisez le modèle suivant pour fournir les paramètres et les valeurs nécessaires :

   Important

   Examinez attentivement le modèle et adaptez son contenu à votre environnement.

   LoadModule request_module modules/mod_request.so
   LoadModule auth_gssapi_module modules/mod_auth_gssapi.so
   # Some Apache configurations might require these modules.
   # LoadModule auth_form_module modules/mod_auth_form.so
   # LoadModule session_module modules/mod_session.so
   
   # Nothing needs to be served over HTTP.  This virtual host simply redirects to
   # HTTPS.
   <VirtualHost *:80>
     DocumentRoot /var/www/html
     RewriteEngine              On
     RewriteRule     ^(.*)$     https://%{HTTP_HOST}$1 [R,L]
   </VirtualHost>
   
   <VirtualHost *:443>
     # This needs to match the certificates you generated.  See the CN and X509v3
     # Subject Alternative Name in the output of:
     # openssl x509 -text -in /etc/pki/tls/certs/localhost.crt
     ServerName www.example.com
   
     DocumentRoot /var/www/html
     SSLEngine on
     SSLCertificateFile /etc/pki/tls/certs/localhost.crt
     SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
     SSLCACertificateFile /etc/pki/CA/certs/ca.crt
   
     SSLProxyEngine on
     SSLProxyCACertificateFile /etc/pki/CA/certs/ca.crt
     # It is critical to enforce client certificates. Otherwise, requests can
     # spoof the X-Remote-User header by accessing the /oauth/authorize endpoint
     # directly.
     SSLProxyMachineCertificateFile /etc/pki/tls/certs/authproxy.pem
   
     # To use the challenging-proxy, an X-Csrf-Token must be present.
     RewriteCond %{REQUEST_URI} ^/challenging-proxy
     RewriteCond %{HTTP:X-Csrf-Token} ^$ [NC]
     RewriteRule ^.* - [F,L]
   
     <Location /challenging-proxy/oauth/authorize>
         # Insert your backend server name/ip here.
         ProxyPass https://<namespace_route>/oauth/authorize
         AuthName "SSO Login"
         # For Kerberos
         AuthType GSSAPI
         Require valid-user
         RequestHeader set X-Remote-User %{REMOTE_USER}s
   
         GssapiCredStore keytab:/etc/httpd/protected/auth-proxy.keytab
         # Enable the following if you want to allow users to fallback
         # to password based authentication when they do not have a client
         # configured to perform kerberos authentication.
         GssapiBasicAuth On
   
         # For ldap:
         # AuthBasicProvider ldap
         # AuthLDAPURL "ldap://ldap.example.com:389/ou=People,dc=my-domain,dc=com?uid?sub?(objectClass=*)"
       </Location>
   
       <Location /login-proxy/oauth/authorize>
       # Insert your backend server name/ip here.
       ProxyPass https://<namespace_route>/oauth/authorize
   
         AuthName "SSO Login"
         AuthType GSSAPI
         Require valid-user
         RequestHeader set X-Remote-User %{REMOTE_USER}s env=REMOTE_USER
   
         GssapiCredStore keytab:/etc/httpd/protected/auth-proxy.keytab
         # Enable the following if you want to allow users to fallback
         # to password based authentication when they do not have a client
         # configured to perform kerberos authentication.
         GssapiBasicAuth On
   
         ErrorDocument 401 /login.html
       </Location>
   
   </VirtualHost>
   
   RequestHeader unset X-Remote-User

   Note

   L'adresse https://<namespace_route> est la route vers le serveur OAuth et peut être obtenue en exécutant oc get route -n openshift-authentication.

3. Mettez à jour la strophe identityProviders dans la ressource personnalisée (CR) :

   identityProviders:
     - name: requestheaderidp
       type: RequestHeader
       requestHeader:
         challengeURL: "https://<namespace_route>/challenging-proxy/oauth/authorize?${query}"
         loginURL: "https://<namespace_route>/login-proxy/oauth/authorize?${query}"
         ca:
           name: ca-config-map
           clientCommonNames:
           - my-auth-proxy
           headers:
           - X-Remote-User

4. Vérifier la configuration.

   1. Confirmez que vous pouvez contourner le proxy en demandant un jeton en fournissant le certificat client et l'en-tête corrects :

      # curl -L -k -H "X-Remote-User: joe" \
         --cert /etc/pki/tls/certs/authproxy.pem \
         https://<namespace_route>/oauth/token/request

   2. Confirmez que les demandes qui ne fournissent pas le certificat du client échouent en demandant un jeton sans le certificat :

      # curl -L -k -H "X-Remote-User: joe" \
         https://<namespace_route>/oauth/token/request

   3. Confirmez que la redirection challengeURL est active :

      # curl -k -v -H 'X-Csrf-Token: 1' \
         https://<namespace_route>/oauth/authorize?client_id=openshift-challenging-client&response_type=token

      Copiez la redirection challengeURL pour l'utiliser dans l'étape suivante.

   4. Exécutez cette commande pour afficher une réponse 401 avec un défi de base WWW-Authenticate, un défi de négociation ou les deux défis :

      # curl -k -v -H 'X-Csrf-Token: 1' \
         <challengeURL_redirect + query>

   5. Tester la connexion à l'OpenShift CLI (oc) avec et sans l'utilisation d'un ticket Kerberos :

      1. Si vous avez généré un ticket Kerberos en utilisant kinit, détruisez-le :

         # kdestroy -c nom_du_cache 1

         1

         Veillez à indiquer le nom de votre cache Kerberos.

      2. Connectez-vous à l'outil oc en utilisant vos identifiants Kerberos :

         # oc login -u <nom d'utilisateur>

         Saisissez votre mot de passe Kerberos à l'invite.

      3. Déconnectez-vous de l'outil oc:

         # oc logout

      4. Utilisez vos identifiants Kerberos pour obtenir un ticket :

         # kinit

         Saisissez votre nom d'utilisateur et votre mot de passe Kerberos à l'invite.

      5. Confirmez que vous pouvez vous connecter à l'outil oc:

         # oc login

         Si votre configuration est correcte, vous êtes connecté sans avoir à saisir d'informations d'identification distinctes.