Authent

Authentification Kerberos pour Keystone (OpenStack)

Par Gauvain Pocentek, Consultant Cloud @Objectif Libre

Cet article décrit comment renforcer la sécurité de l’authentification Keystone dans OpenStack grâce à Kerberos

Public visé : administrateurs OpenStack, familiers avec le déploiement et les concepts de Keystone.

Problématique de départ

Keystone est le composant responsable de l’authentification sur une plateforme OpenStack. Par défaut, l’authentification nécessite l’envoi d’un login et d’un mot de passe par un appel d’API. Les mots de passe sont généralement stockés en clair dans un fichier texte, souvent non chiffré : autant dire que ce n’est pas une méthode très sécurisée. Même si le mot de passe est demandé lorsque le fichier RC est sourcé (en utilisant un fichier RC téléchargé depuis Horizon par exemple), ce mot de passe réside toujours dans l’environnement.

Keystone peut s’appuyer sur des systèmes d’authentification externes pour valider l’authentification des utilisateurs. Une fois l’authentification faite, Keystone procède de manière standard en générant un token, que l’utilisateur pourra utiliser pour s’authentifier auprès des autres API OpenStack.

Voyons donc comment activer le support de l’authentification avec ticket Kerberos, en complément de l’authentification standard.

Prérequis

Pour réaliser les manipulations, nous vous conseillons d’avoir à disposition un déploiement fonctionnel de Keystone, ainsi qu’un service Kerberos/LDAP (installé manuellement, un serveur freeIPA, Active Directory ou tout autre système de ce type). Les concepts et l’installation de ces services ne seront pas couverts ici.

Les exemples utiliseront les informations suivantes :

  • Domaine Kerberos : OL.CORP
  • Nom du domain Keystone : olcorp
  • Serveurs Kerberos (KDC et admin) : kerberos.ol.corp
  • URL Keystone : https://ks-krb.ol.corp:5000
  • Utilisateur de test : user1

Configurons !

Les étapes suivantes sont nécessaires pour l’activation de l’authentification Kerberos :

  • Création d’un principal et génération d’un fichier keytab pour le serveur httpd exposant Keystone: c’est ce serveur httpd qui est en fait responsable de l’authentification Kerberos, et non Keystone
  • Configuration du service httpd pour supporter l’authentification standard, et l’authentification Kerberos (sur une URL dédiée)
  • Ajout du support LDAP dans Keystone
  • Configuration de la section [auth] de Keystone pour le support Kerberos

Configuration Kerberos

Le serveur httpd exécutant le script WSGI de Keystone doit être kerberisé. Il faut par conséquent créer un principal et un fichier keytab pour ce service. Le procédé dépend du type de serveur Kerberos utilisé.

L’exemple suivant illustre le procédé avec un serveur MIT Kerberos :

# kadmin.local
kadmin.local: addprinc -randkey HTTP/ks-krb.ol.corp
kadmin.local: ktadd -k /tmp/http.keytab HTTP/ks-krb.ol.corp

Copiez le fichier /tmp/http.keytab sur le serveur Keystone (par exemple dans /etc/apache2 or /etc/httpd). Il sera utilisé lors de la configuration du service httpd.

Authentification LDAP pour Keystone

Dans cet exemple, nous utilisons un domaine Keystone dédié, configuré pour accéder à un serveur LDAP. Plusieurs avantages à ce type de configuration :

  • Le domaine par défaut contient les utilisateurs système et n’a pas à être modifié
  • L’authentification login/mot de passe est toujours fonctionnelle pour l’administrateur de la plateforme
  • Pas besoin d’ajouter les utilisateurs système à l’annuaire
  • L’ajout de nouveaux domaines, utilisant d’autres annuaires, est facilité

Modifiez le fichier keystone.conf pour activer le support des domaines LDAP :

[identity]
domain_specific_drivers_enabled = True
domain_config_dir = /etc/keystone/domains

Le dossier /etc/keystone/domains/ contient la configuration LDAP pour chacun des domaines.

Les paramètres pour le domaine olcorp sont définis dans /etc/keystone/domains/keystone.olcorp.conf. Attention : respectez bien le format de nom de fichier keystone.DOMAIN_NAME.conf :

[identity]
driver = ldap

[ldap]
url = ldaps://ldap.ol.corp
suffix = dc=ol,dc=corp
user = cn=keystone,ou=apps,dc=ol,dc=corp
password = s3cr3t
...

La documentation Keystone fournit la liste complète des paramètres utilisables.

Redémarrez Keystone et configurez le domaine :

$ sudo systemctl restart apache2  # or httpd
$ . adminrc  # login en tant qu'admin cloud
$ openstack domain create olcorp
$ PROJECT_ID=$(openstack project create --domain olcorp test -f value -c id)
$ USER_ID=$(openstack user show user1 -f value -c id)
$ openstack role add --user $USER_ID --project $PROJECT_ID _member_

Vous pouvez maintenant vous authentifier avec un utilisateur LDAP dans le domaine olcorp.

Configuration Kerberos pour httpd

La configuration du serveur httpd exposera 2 URLs après modification :

  • Sur / : authentification par login / mot de passe
  • Sur /krb/ : authentication Kerberos

Seule l’URL /krb/v3/auth/tokens doit être kerberisée.

Modifiez la configuration httpd/WSGI de Keystone. L’emplacement du fichier dépend de la distribution OpenStack utilisée (sur Ubuntu : /etc/apache2/sites-enabled/wsgi-keystone.conf) :

<VirtualHost *:5000>
    ...
    WSGIScriptAlias /krb /usr/bin/keystone-wsgi-public
    WSGIScriptAlias / /usr/bin/keystone-wsgi-public
    ...

    <Location "/krb/v3/auth/tokens">
        LogLevel debug
        AuthType              Kerberos
        AuthName              "Kerberos Login"
        KrbMethodNegotiate    On
        KrbMethodK5Passwd     Off
        KrbServiceName        HTTP
        KrbAuthRealms         OL.CORP
        Krb5KeyTab            /path/to/http.keytab
        KrbVerifyKDC          Off
        KrbLocalUserMapping   On
        KrbAuthoritative      On
        Require valid-user
        SetEnv REMOTE_DOMAIN olcorp
    </Location>
</VirtualHost>

Une fois un utilisateur authentifié par httpd grâce au ticket Kerberos, une variable REMOTE_USER est fournie à Keystone, qui accèdera aux informations de l’utilisateur grâce à la configuration LDAP.

La variable REMOTE_DOMAIN permet de spécifier à Keystone dans quel domaine trouver l’utilisateur.

Modifiez keystone.conf pour activer ce comportement (kerberos doit être défini) :

[auth]
methods = external,password,token,oauth1,kerberos

Redémarrez httpd pour appliquer les changements :

$ sudo systemctl restart apache2  # or httpd

Tests d’authentification

L’authentification par login / mot de passe est encore fonctionnelle :

$ source keystonerc  # downloaded from horizon for example
$ openstack token issue

Cependant, vous pouvez également vous authentifier grâce à un ticket Kerberos :

$ kinit
Password for user1@OL.CORP:
$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: user1@OL.CORP
$ export OS_AUTH_URL=https://ks-krb.ol.corp:5000/krb/v3
$ export OS_AUTH_TYPE=v3kerberos
$ export OS_PROJECT_DOMAIN_ID=17957a91111c44378b08c1f0c58b9e60
$ export OS_PROJECT_NAME=test
$ export OS_IDENTITY_API_VERSION=3
$ openstack token issue -f value -c id
gAAAAABahuuzhdSxSL2vgD99umDKU3Kd_6HQuoahfGm...

Conclusion

L’authentification Kerberos est devenue courante et fournit un bon niveau de sécurité. Configurer Keystone pour l’utiliser est un procédé simple, et n’empêche pas une authentification plus standard.

Si vous avez un service Kerberos à disposition, il serait dommage de priver vos utilisateurs de ce type d’authentification !