Dans un environnement distribué, l'authentification Kerberos permet de sécuriser l'accès aux services. Après authentification réussie via Kerberos, et en l'absence de Sentry, l'accès aux services est généralement possible. Cependant, certains services comme HDFS et HBase implémentent des restrictions ACL supplémentaires nécessitent des autorisations spécifiques. Sentry ne gère que Hive, tandis que HDFS et HBase utilisent des ACL, bien que Sentry puisse gérer HDFS via ces mêmes ACL.

Abréviations courantes

• add_principal, addprinc, ank
• delete_principal, delprinc
• ktadd, xst
• change_password, cpw

Connexion à kadmin

Pour accéder à l'interface d'administration Kerberos:

kadmin.local

Sur les nœuds non-kadmin, authentifiez-vous d'abord avec un principal ayant des droits d'administration, puis exécutez kadmin et entrez le mot de passe.

Création d'un principal avec clé aléatoire

Cette méthode crée un principal utilisable uniquement pour générer un keytab:

addprinc -randkey utilisateur/serveur1@DOMAINE.EXAMPLE

Génération de keytab

La commande suivante génère un ficheir keytab:

ktadd -k /chemin/vers/fichier.keytab nom_du_principal

Par défaut, cette commande génère un mot de passe aléatoire long qui remplace le mot de passe existant. Après remplacement, l'ancien mot de passe ne fonctionne plus, seul le keytab peut être utilisé. Pour conserver l'authentification par mot de passe, utilisez le paramètre -norandkey:

ktadd -norandkey -k /keytabs/utilisateur.keytab utilisateur/serveur1@DOMAINE.EXAMPLE hote/serveur1@DOMAINE.EXAMPLE

Création d'un principal avec mot de passe spécifique

Cette commande crée un principal et demande de définir un mot de passe:

addprinc administrateur/admin

Génération de keytab pour plusieurs principals

Il est possible de générer un keytab contenant plusieurs principals:

ktadd -norandkey -k /keytabs/utilisateur.keytab utilisateur/serveur1@DOMAINE.EXAMPLE hote/serveur1@DOMAINE.EXAMPLE

Vérification des informations d'authentification dans un keytab

La commande suivante affiche les informations contenues dans un keytab:

klist -ket fichier.keytab

Gestion des tickets dans les environnements multi-processus

Dans un environnement où plusieurs scripts s'exécutent en parallèle, l'authentification kinit peut être écrasée. Il est donc nécessaire de sauvegarder temporairement les tickets générés avant d'exécuter kinit:

export KRB5CCNAME=/tmp/krb5_cache_dev
kinit -kt fichier.keytab principal

Consultation des tickets d'authentification

Pour afficher les informations d'authentification de l'utilisateur actuel:

klist -e

Exemple de sortie:

# klist -ket fichier.keytab

Keytab name: FILE:fichier.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   7 2018-07-30T10:19:16 hbase-flink@demo.com (des-cbc-md5) 
   7 2018-07-30T10:19:16 hbase-flink@demo.com (aes128-cts-hmac-sha1-96) 
   7 2018-07-30T10:19:16 hbase-flink@demo.com (aes256-cts-hmac-sha1-96) 
   7 2018-07-30T10:19:16 hbase-flink@demo.com (des3-cbc-sha1) 
   7 2018-07-30T10:19:16 hbase-flink@demo.com (arcfour-hmac)

Liste des principals

Pour afficher tous les principals existants:

listprincs

Modification du mot de passe d'un principal

Pour modifier le mot de passe du principal administrateur/admin:

change_password -pw nouveau_mot_de_passe administrateur/admin
# ou version abrégée
cpw

Suppression d'un principal

Pour supprimer un principal:

delete_principal administrateur/admin

Exemples pratiques

1. Utilisation simultanée de mot de passe et keytab

Lorsqu'on crée un principal avec mot de passe, puis qu'on génère un keytab sans l'option -norandkey, le mot de passe original est remplacé par une longue chaîne aléatoire. Avec l'option -norandkey, l'authentification par mot de passe et par keytab reste possible:

addprinc utilisateur_test
ktadd -norandkey -k /opt/keytabs/utilisateur_test.keytab utilisateur_test

Dans ce cas, l'authentification fonctionne à la fois avec le mot de passe et avec le keytab.

2. Cycle de vie des tickets Kerberos

Les tickets Kerberos ont deux durées de vie: la durée de vie du ticket (ticket lifetime) et la durée de renouvellement (renewable lifetime).

Lorsque la durée de vie du ticket expire, le ticket n'est plus utilisable. Si la durée de renouvellement est supérieure à la durée de vie du ticket, il est possible de renouveler le ticket pendant sa durée de vie, jusqu'à atteindre la limite de renouvellement. Une fois la durée de renouvellement atteinte, le ticket ne peut plus être renouvelé après son expiration, et une erreur "KDC can't fulfill requested option while renewing credentials" se produit. Il faut alors exécuter à nouveau kinit pour obtenir un nouveau ticket.

L'avantage des tickets renouvelables par rapport aux tickets avec une longue durée de vie est que le KDC peut rejeter les demandes de renouvelllement (par exemple, si un compte est compromis et qu'un ticket renouvelable pourrait être entre les mains d'un attaquant).

Par exemple:

• ticket_lifetime = 1j
• renew_lifetime = 7j

Dans les 24h suivant la connexion, il est possible de renouveler le ticket jusqu'à 7 jours après la connexion initiale. Si le ticket n'est pas renouvelé dans les 24h, il ne pourra plus être renouvelé. Après un renouvellement, la durée de vie du ticket est réinitialisée à 24h. Dans un scénario pratique, si un développeur prévoit de terminer un travail en 3 jours mais que le travail prend plus de temps, il peut renouveler son ticket sans avoir à ressaisir son mot de passe ou à utiliser un keytab.

Kerberos permet d'obtenir un ticket (également appelé TGT) via kinit. Pendant la validité de ce ticket, aucun mot de passe n'est requis. Le ticket peut être renouvelé plusieurs fois jusqu'à sa date d'expiration finale. Voici un exemple montrant un ticket valide du 07 décembre au 08 décembre (une journée), mais qui peut être renouvelé avec kinit -R jusqu'au 12 décembre. Après cette date, la commande kinit -R ne fonctionnera plus.

La commande kinit -R actualise l'heure de début de validité ("Valid starting") à l'heure actuelle, ce qui repousse également l'heure d'expiration ("Expires"). Cependant, la date limite de renouvellement ("renew until") reste celle déterminée lors de la première authentification.

Ce ticket est indépendant du keytab, qui n'est qu'un fichier contenant le mot de passe chiffré.

Exécutez la commande klist pour vérifier les valeurs effectivement accordées par le système.

Ticket cache: FILE:/tmp/krb5cc_1234
Default principal:utilisateur@DOMAINE.EDU
Valid starting     Expires            Service principal
12/07/15 13:00:05  12/08/15 13:00:01  krbtgt/DOMAINE.EDU@DOMAINE.EDU
        renew until 12/12/15 15:48:44

Le ticket expirera comme un ticket normal après 24 heures, mais vous pouvez le renouveler plusieurs fois avant son expiration, jusqu'à la date d'expiration finale (12 décembre dans l'exemple ci-dessus). Vous devez exécuter la commande kinit de manière interactive car vous devrez fournir votre phrase secrète Kerberos; cela ne peut pas être inclus dans une tâche cron ou autre situation non supervisée.