Durcissement de la sécurité HDFS avec des exemples pratiques

Intro

Ce guide montre comment durcir HDFS par petites étapes vérifiables. Chaque exemple commence par une observation en lecture seule, suivie d’un changement minimal et circonscrit, d’une commande de vérification, puis d’un chemin de récupération si un problème survient. La priorité est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d’impact, utiliser des paramètres fictifs plutôt que des secrets, et toujours confirmer le résultat.

Public cible : ingénieurs qui déploient, exploitent ou intègrent HDFS (Hadoop 2.7+ et Hadoop 3.x). Les systèmes connexes comme Spark, NiFi et Kafka ne sont mentionnés que lorsqu’ils influencent les prérequis ou la vérification.

Thèmes clés :

Authentification et sécurité du transport (Kerberos, TLS (Transport Layer Security) : protocole standard de chiffrement des communications, RPC (Remote Procedure Call) : appels de procédure à distance protégés)
Autorisation (permissions POSIX (Portable Operating System Interface) : sémantique Unix, ACL (Access Control List) : listes de contrôle d’accès, contrôles de superutilisateur)
Protection des données au repos (zones de chiffrement, KMS (Key Management Server) : service de gestion des clés Hadoop)
Audit et diagnostic (journaux, vérifications canaris)

Inventaire des versions et de l’environnement

Commencez par capturer ce qui fonctionne réellement. Séparez l’observation de l’intervention.

Prérequis :

Accès shell à un hôte NameNode
CLI HDFS disponible dans le PATH
Aucun changement de configuration pour l’instant

Inventaire en lecture seule (notez l’horodatage et les sorties) :

Versions de Hadoop et HDFS

hdfs version

Topologie (noms logiques des NameNodes et JournalNodes)

hdfs getconf -namenodes
hdfs getconf -secondarynamenodes  # si utilisé
hdfs getconf -confKey dfs.namenode.shared.edits.dir

Mode d’authentification et protection RPC

hdfs getconf -confKey hadoop.security.authentication     # attendu : 'kerberos' ou 'simple'
hdfs getconf -confKey hadoop.rpc.protection              # 'auth', 'integrity', ou 'privacy'

Politique des interfaces Web et TLS

hdfs getconf -confKey dfs.http.policy                    # 'HTTP_ONLY' ou 'HTTPS_ONLY'

Chiffrement des transferts de données et jetons de blocs

hdfs getconf -confKey dfs.encrypt.data.transfer          # 'true' ou 'false'
hdfs getconf -confKey dfs.block.access.token.enable      # généralement 'true'

Système de permissions et paramètres superutilisateur

hdfs getconf -confKey dfs.permissions.enabled
hdfs getconf -confKey dfs.permissions.superusergroup
hdfs getconf -confKey dfs.cluster.administrators
hdfs getconf -confKey fs.permissions.umask-mode

Mappage des groupes (local ou LDAP (Lightweight Directory Access Protocol) : annuaire d’entreprise)

hdfs getconf -confKey hadoop.security.group.mapping

Permissions de base de l’espace de noms HDFS

hdfs dfs -ls -d / /user /tmp 2>/dev/null
hdfs dfs -getfacl / /tmp 2>/dev/null

Définissez des résultats attendus avant tout changement. Exemple : « HTTPS_ONLY pour les interfaces Web, Kerberos + hadoop.rpc.protection=privacy, dfs.encrypt.data.transfer=true, umask 027, /tmp en 1777 avec sticky bit, jetons de bloc activés. » Toute déviation est un candidat pour une correction circonscrite.

Chemin de configuration sûr

Appliquez un seul changement à la fois, avec un rayon d’impact connu et un retour arrière prévu. Utilisez un créneau de maintenance pour les changements qui redémarrent les NameNodes ou DataNodes.

Imposer HTTPS sur les interfaces Web NameNode et DataNode

Étendue : accès des administrateurs aux interfaces Web HDFS
Prérequis : keystores/truststores valides sur les hôtes NameNode/DataNode ; paramètres SSL dans ssl-server.xml/ssl-client.xml ; sauvegarde de core-site.xml et hdfs-site.xml
Observation :

hdfs getconf -confKey dfs.http.policy  # si HTTP_ONLY, les interfaces Web sont en clair

Changement (forcer HTTPS uniquement) :
Modifier hdfs-site.xml sur les NameNodes et DataNodes :
dfs.http.policy = HTTPS_ONLY
Vérifier que ssl-server.xml référence le keystore à <KEYSTORE_PATH> et son gestionnaire de mots de passe.
Vérification :
Redémarrer les services impactés, un rôle à la fois.
Accéder à https://<namenode-host>:9871 et https://<datanode-host>:9865
Signaux d’échec : SSLHandshakeException dans les journaux ; erreurs de navigateur sur la chaîne de certificats.
Récupération : rétablir dfs.http.policy à sa valeur précédente et redémarrer le rôle en échec.

Chiffrer les RPC HDFS et les transferts de données

Étendue : confidentialité et intégrité des protocoles client↔NameNode et client/DataNode
Prérequis : Kerberos configuré pour le cluster si vous utilisez une protection basée sur SASL (Simple Authentication and Security Layer) : couche d’authentification et de sécurité générique
Observation :

hdfs getconf -confKey hadoop.rpc.protection          # attendu : 'privacy' pour le chiffrement
hdfs getconf -confKey dfs.encrypt.data.transfer      # attendu : 'true'

Changement :
Dans core-site.xml : hadoop.rpc.protection = privacy
Dans hdfs-site.xml : dfs.encrypt.data.transfer = true
Vérification :
Redémarrage progressif (rolling) des NameNodes et DataNodes.
Depuis un client authentifié Kerberos :

kinit -kt /path/to/<USER>.keytab <USER_PRINCIPAL>
hdfs dfs -ls /

Contrôler les journaux : pas de rétrogradation de la QOP (Quality of Protection) : niveau de protection SASL, ni d’avertissements de transfert en clair.
Signaux d’échec : erreurs côté clients du type Failed on local exception: java.io.EOFException ou erreurs de négociation SASL.
Récupération : restaurer les valeurs précédentes et redémarrer les composants dans l’ordre inverse.

Durcir les permissions et les paramètres par défaut

Étendue : sécurité de l’espace de noms et moindre privilège
Observation :

hdfs getconf -confKey dfs.permissions.enabled
hdfs getconf -confKey fs.permissions.umask-mode
hdfs dfs -stat %a /
hdfs dfs -stat %a /tmp

Changement :
S’assurer que les permissions sont appliquées : dfs.permissions.enabled = true
Définir l’umask par défaut à 027 : fs.permissions.umask-mode = 027
Sécuriser les répertoires courants :

hdfs dfs -chmod 755 /
hdfs dfs -chmod 1777 /tmp
hdfs dfs -mkdir -p /user
hdfs dfs -chmod 755 /user

Vérification :

hdfs dfs -touchz /tmp/perm-test
hdfs dfs -stat %a /tmp/perm-test     # attendu : 644 avec umask 027 pour les fichiers ; 750 par défaut pour les répertoires

Tenter une écriture inter-utilisateurs dans /tmp depuis un autre compte ; seul le propriétaire doit pouvoir supprimer ses fichiers grâce au sticky bit.
Signaux d’échec : 777 inattendu sur les nouveaux répertoires ; des utilisateurs peuvent supprimer les fichiers des autres dans /tmp.
Récupération : réappliquer chmod/umask aux valeurs souhaitées ; confirmer avec stat.

Définir délibérément les groupes superutilisateur et administrateurs

Étendue : qui peut contourner les contrôles et effectuer des opérations d’administration
Observation :

hdfs getconf -confKey dfs.permissions.superusergroup
hdfs getconf -confKey dfs.cluster.administrators
hdfs groups <USER>     # vérifier la résolution des groupes OS/LDAP pour les opérateurs

Changement :
Limiter dfs.permissions.superusergroup à un petit groupe audité (ex. : hadoop-admins).
S’assurer que seuls les administrateurs requis figurent dans dfs.cluster.administrators.
Vérification : les opérateurs hors du groupe doivent se voir refuser les opérations privilégiées (ex. : -setQuota à la racine).
Récupération : ajouter temporairement un compte de secours (break-glass) aux groupes admin ; retirer après incident.

Créer des zones de chiffrement pour les données sensibles

Étendue : données au repos sous des chemins précis
Prérequis : Hadoop KMS (Key Management Server) joignable ; un fournisseur de clés configuré (ex. : kms://http@<kms-host>:<port>/kms)
Observation :

hdfs crypto -listZones
hadoop key list -provider <KMS_URI>

Changement (exemple : création d’une nouvelle zone à /secure) :

# Créer une clé dans le KMS
hadoop key create -provider <KMS_URI> <KEY_NAME>

# Créer le répertoire et la zone
hdfs dfs -mkdir -p /secure
hdfs crypto -createZone -keyName <KEY_NAME> -path /secure

Vérification :

hdfs crypto -listZones | grep /secure
hdfs dfs -put /etc/hosts /secure/test

Confirmer côté DataNode que les blocs sont chiffrés au repos (vérification indirecte via la présence d’une zone de chiffrement et des accès KMS dans les journaux).
Signaux d’échec : KeyProvider not found ou Key not found ; les écritures dans la zone échouent.
Récupération : supprimer la zone uniquement si elle est vide ou déplacer les données ; sinon corriger la configuration KMS et réessayer.

Intégrer une autorisation centralisée (optionnel)

Si vous utilisez Apache Ranger ou un plan de contrôle similaire, assurez-vous que le plugin HDFS est activé et que des politiques cohérentes avec les permissions POSIX/ACL sont en place. Testez avec un utilisateur au moindre privilège pour valider la logique d’autorisation/refus. Si Spark ou NiFi écrivent dans HDFS, vérifiez que leurs identités de service sont couvertes à la fois par les permissions POSIX/ACL et par les politiques centrales.

Vérification et diagnostic

Utilisez des contrôles répétables et des signaux de bon fonctionnement connus après chaque changement.

Contrôle d’identité (Kerberos) :

klist -kte /path/to/<USER>.keytab | head -n 1
kinit -kt /path/to/<USER>.keytab <USER_PRINCIPAL>

Attendu : ticket mis en cache, pas d’échec de pré-authentification. TGT (Ticket-Granting Ticket) : ticket de service Kerberos utilisé pour obtenir d’autres tickets.

Permissions et ACL :

hdfs dfs -getfacl / /tmp /user
hdfs dfs -setfacl -m u:<TEST_USER>:r-x /tmp
hdfs dfs -getfacl /tmp | grep <TEST_USER>

Attendu : l’ACL montre TEST_USER avec r-x ; TEST_USER ne peut pas supprimer les fichiers des autres sous /tmp.

Protection des transferts et des RPC :
Les journaux du NameNode doivent indiquer une QOP (Quality of Protection) de type privacy lorsque Kerberos est activé et hadoop.rpc.protection=privacy.
Aucun avertissement de transfert en clair lorsque dfs.encrypt.data.transfer=true.

Piste d’audit :
Les journaux d’audit du NameNode doivent consigner les opérations autorisées/refusées avec l’utilisateur, l’IP et le chemin.
Avec Ranger, confirmer que les audits du plugin HDFS montrent les correspondances de politiques attendues.

Santé et mode sécurisé (safemode) :

hdfs dfsadmin -report | head -n 20
hdfs fsck / -files -blocks -locations | head -n 20

Attendu : tous les DataNodes en ligne ; aucun bloc manquant introduit par les changements.

Modes de panne et récupération

Mauvaise configuration TLS des interfaces Web
Symptôme : SSLHandshakeException ; interfaces Web inaccessibles sur 9871/9865.
Action : repasser dfs.http.policy à HTTP_ONLY, redémarrer, corriger keystore/truststore, puis réappliquer HTTPS_ONLY au prochain créneau.

Rupture Kerberos ou de la protection RPC
Symptôme : erreurs de négociation SASL ; les journaux NameNode montrent une QOP incompatible.
Action : remettre temporairement hadoop.rpc.protection à la valeur précédente, redémarrer les NameNodes, valider keytabs et principaux Kerberos, puis réactiver privacy.

Le chiffrement des transferts bloque les pipelines
Symptôme : écritures figées ; journaux DataNode avec erreurs de chiffrement.
Action : revenir à la valeur précédente de dfs.encrypt.data.transfer sur DNs et clients ; redémarrer les DNs ; réessayer avec des chiffrements compatibles et les politiques JCE (Java Cryptography Extension) requises par votre distribution Java.

Umask ou chmod trop stricts bloquent des utilisateurs
Symptôme : échecs de jobs dus à l’absence de lecture/exécution sur des chemins partagés.
Action : restaurer l’umask au dernier bon connu (ex. : 022) et réappliquer des ACLs de groupe pour la collaboration. Valider avec un job canari avant de rétablir des règles plus strictes.

Clé de zone de chiffrement introuvable ou panne KMS
Symptôme : écritures dans la zone de chiffrement en échec ; erreurs Key not found.
Action : rétablir la connectivité KMS ou suspendre temporairement les écritures vers la zone. Ne pas supprimer une zone tant qu’elle contient des données.

Approche générale de retour arrière :

Conserver des sauvegardes des fichiers modifiés (core-site.xml.bak, hdfs-site.xml.bak).
Modifier une propriété par périmètre de redémarrage quand c’est possible.
Utiliser des redémarrages progressifs : NameNode en veille d’abord, puis actif via bascule maîtrisée, puis DataNodes par petits lots.
Si l’instabilité persiste, entrer en mode sécurisé, rétablir la configuration, puis redémarrer pour sortir proprement du mode sécurisé.

Liste d’opérations (checklist)

Exécutez ces points à fréquence régulière (hebdomadaire ou mensuelle) et avant/après tout changement majeur.

Identité et accès
Vérifier que les keytabs Kerberos de service et d’utilisateurs sont dans la fenêtre de rotation ; renouveler un TGT (Ticket-Granting Ticket) de test.
Confirmer dfs.permissions.enabled=true et fs.permissions.umask-mode=027.
Revoir les membres de dfs.permissions.superusergroup et dfs.cluster.administrators.
Contrôler des ACLs sur /, /user, /tmp et les racines de projets sensibles.

Sécurité du transport
Confirmer dfs.http.policy=HTTPS_ONLY ; vérifier la validité et les SANs (Subject Alternative Names) : alternatives de nom de sujet, des certificats.
Valider hadoop.rpc.protection=privacy et dfs.encrypt.data.transfer=true sur NameNodes, DataNodes et clients.

Données au repos
Lister les zones de chiffrement et les clés KMS utilisées ; documenter les propriétaires et les plans de rotation.
Tester une écriture/lecture dans une zone de chiffrement et confirmer les traces d’accès côté KMS.

Audit et diagnostic
Vérifier l’ingestion/rétention des journaux d’audit du NameNode ; rechercher des refus et des pics d’activité.
Avec Ranger, vérifier le heartbeat du plugin et l’actualité du cache des politiques.

Dépendances
Les utilisateurs de service Spark, NiFi et Kafka peuvent lister leurs chemins HDFS requis ; moindre privilège confirmé.
Un workflow canari (petite lecture/écriture) réussit avec la QOP attendue et les entrées d’audit correspondantes.

Préparation à la reprise
Des sauvegardes versionnées de core-site.xml et hdfs-site.xml existent.
Le runbook de redémarrage progressif et de bascule est à jour et testé.

Conclusion

Le durcissement de HDFS est le plus efficace lorsque chaque étape est circonscrite par version, observable et réversible. Commencez par un inventaire précis, puis appliquez de petits changements justifiés : imposer HTTPS, protéger les RPC et les transferts de données, resserrer permissions et ACLs, et utiliser des zones de chiffrement pour les chemins sensibles. Après chaque modification, vérifiez un signal clair et gardez un plan de retour arrière éprouvé. Cette discipline rend les échecs visibles tôt, protège les secrets, limite le rayon d’impact et maintient votre cluster en sécurité tout en restant productif.