Version: 1.3.1.0

Chiffrement dans ODP

ODP applique le chiffrement à plusieurs niveaux : TLS en transit pour toute la communication entre services, chiffrement transparent au repos pour HDFS, et chiffrement wire pour les protocoles RPC. Ce document couvre chaque couche et explique comment la configurer via Ambari.

Chiffrement en transit (TLS)

Toute la communication inter-services dans un cluster ODP sécurisé passe par TLS. Cela inclut :

Transferts de blocs HDFS (DataNode ↔ client, DataNode ↔ DataNode)
Communication YARN Resource Manager ↔ Node Manager
Communication HBase master ↔ RegionServer
Connexions clients ZooKeeper
Communication serveur Ambari ↔ agent
Passerelle Knox (TLS côté client)
Ranger Admin, Ranger KMS et toutes les interfaces web

Auto-TLS (recommandé)

La fonctionnalité Auto-TLS d'Ambari automatise la gestion du cycle de vie des certificats sur l'ensemble du cluster. Elle :

Génère une CA interne au cluster ou s'intègre avec la CA Dogtag de FreeIPA.
Émet des certificats signés pour chaque agent Ambari (un par hôte).
Distribue les certificats et configure automatiquement tous les services.
Gère le renouvellement des certificats.

Activer Auto-TLS lors de la configuration initiale du cluster :

# Exécuter sur l'hôte du serveur Ambari
/var/lib/ambari-server/resources/scripts/configs.py \
  --action=set \
  --cluster=<nom-cluster> \
  --config-type=cluster-env \
  --key=security_enabled \
  --value=true

En pratique, Auto-TLS est activé via l'assistant de configuration Ambari avant le déploiement des services. Une fois activé, tous les services sont configurés avec TLS automatiquement.

Gestion manuelle des certificats

Pour les environnements où Auto-TLS n'est pas utilisé, les certificats doivent être générés et distribués manuellement. Emplacements clés par service :

Service	Chemin keystore / truststore
HDFS (NameNode, DataNode)	`/etc/security/serverKeys/hdfs.jks`
YARN	`/etc/security/serverKeys/yarn.jks`
HBase	`/etc/security/serverKeys/hbase.jks`
Ranger Admin	`/etc/ranger/admin/conf/ranger-admin-keystore.jks`
Knox	`/usr/odp/current/knox-server/data/security/keystores/gateway.jks`

Générer un certificat signé pour un service :

# Générer la clé et le CSR
keytool -genkeypair -alias hdfs-nn \
  -keyalg RSA -keysize 2048 \
  -validity 730 \
  -keystore /etc/security/serverKeys/hdfs.jks \
  -storepass <mot-de-passe-keystore> \
  -dname "CN=master01.dev01.hadoop.clemlab.com, OU=ODP, O=Clemlab, C=FR"

keytool -certreq -alias hdfs-nn \
  -keystore /etc/security/serverKeys/hdfs.jks \
  -storepass <mot-de-passe-keystore> \
  -file hdfs-nn.csr

# Signer avec votre CA, puis importer :
keytool -importcert -alias ca-root \
  -keystore /etc/security/serverKeys/hdfs.jks \
  -storepass <mot-de-passe-keystore> \
  -file ca.crt

keytool -importcert -alias hdfs-nn \
  -keystore /etc/security/serverKeys/hdfs.jks \
  -storepass <mot-de-passe-keystore> \
  -file hdfs-nn.crt

Chiffrement au repos — HDFS Transparent Data Encryption (TDE)

Le TDE HDFS chiffre les blocs de données sur disque sans nécessiter de modification des applications. Le chiffrement et le déchiffrement sont transparents pour les clients HDFS — le client lit et écrit en clair tandis que le DataNode stocke des données chiffrées.

Architecture

 Client HDFS
     │ lecture/écriture en clair
     ▼
 NameNode (gère les zones de chiffrement + métadonnées DEK)
     │ DEK enveloppé avec la clé de zone
     ▼
 Ranger KMS (Key Management Server)
     │ stocke les clés maîtres (clés de zone)
     ▼
 DataNode (stocke les blocs chiffrés)

Clé de zone : Clé maître stockée dans Ranger KMS. Ne quitte jamais le KMS.
Data Encryption Key (DEK) : Clé par fichier générée par HDFS. Chiffrée (enveloppée) avec la clé de zone. Stockée dans les métadonnées HDFS.
Encrypted Data Encryption Key (EDEK) : Ce qui est stocké dans le fsimage du NameNode.

Installation et configuration de Ranger KMS

Ranger KMS est un service séparé déployé via Ambari (Add Service → Ranger KMS).

Après installation, configurer le backend KMS dans Ambari sous Ranger KMS → Configs :

# Base de données pour le store de clés (MySQL / PostgreSQL)
ranger.ks.jpa.jdbc.url=jdbc:mysql://db-host:3306/rangerkms
ranger.ks.jpa.jdbc.user=rangerkms
ranger.ks.jpa.jdbc.password=<mot-de-passe>

Ranger KMS écoute sur le port 9292 (HTTP) ou 9293 (HTTPS).

Création de zones de chiffrement

Une zone de chiffrement est un répertoire HDFS où tous les fichiers sont automatiquement chiffrés avec une clé de zone spécifique.

# Étape 1 : S'authentifier en tant qu'admin HDFS
kinit -kt /etc/security/keytabs/hdfs.headless.keytab hdfs@DEV01.HADOOP.CLEMLAB.COM

# Étape 2 : Créer une clé dans Ranger KMS
hadoop key create my-zone-key \
  -size 256 \
  -provider kms://https@ranger-kms-host:9293/kms

# Étape 3 : Créer le répertoire HDFS
hdfs dfs -mkdir /encrypted/finance

# Étape 4 : Créer la zone de chiffrement
hdfs crypto -createZone -keyName my-zone-key -path /encrypted/finance

Vérifier la zone :

hdfs crypto -listZones
# Résultat :
# /encrypted/finance  my-zone-key

Tous les fichiers écrits dans /encrypted/finance sont automatiquement chiffrés. Les fichiers existants ne sont pas chiffrés rétroactivement — ils doivent être déplacés dans la zone.

Gestion des clés

Créer, faire pivoter et supprimer des clés via l'API REST Ranger KMS ou le CLI hadoop key :

# Lister toutes les clés
hadoop key list --provider kms://https@ranger-kms-host:9293/kms

# Faire pivoter (rotation) une clé — les nouveaux fichiers utilisent la nouvelle version
hadoop key roll my-zone-key \
  --provider kms://https@ranger-kms-host:9293/kms

# Supprimer une clé (uniquement si aucune zone de chiffrement ne l'utilise)
hadoop key delete my-zone-key \
  --provider kms://https@ranger-kms-host:9293/kms

L'accès aux clés est contrôlé par les politiques Ranger KMS. Seul HDFS et les utilisateurs autorisés peuvent récupérer les DEK.

Accès aux données chiffrées

Les applications n'ont pas besoin de modifications de code pour lire des données chiffrées. Cependant :

Le principal Kerberos de l'application doit avoir la permission DECRYPT_EEK dans la politique Ranger KMS pour la clé concernée.
HDFS gère le déchiffrement de manière transparente lors des lectures.

Accorder l'accès au déchiffrement dans l'interface Ranger KMS sous Service → KMS → Policies :

Ressource : my-zone-key
Utilisateur : hive — Permissions : GET, GET_KEYS, GET_METADATA, GENERATE_EEK, DECRYPT_EEK
Utilisateur : spark — Permissions : GET, GET_METADATA, GENERATE_EEK, DECRYPT_EEK

Chiffrement wire pour RPC

Au-delà de TLS pour les endpoints HTTP/REST, ODP supporte également le chiffrement en vol pour les RPC Hadoop (protocole binaire utilisé entre les clients HDFS et NameNode/DataNode, entre les tâches MapReduce, etc.).

Chiffrement RPC Hadoop

Configurer dans core-site.xml via Ambari :

<property>
  <name>hadoop.rpc.protection</name>
  <!-- Options : authentication (intégrité seulement), integrity, privacy (chiffrement complet) -->
  <value>privacy</value>
</property>

<property>
  <name>dfs.encrypt.data.transfer</name>
  <value>true</value>
</property>

<property>
  <name>dfs.encrypt.data.transfer.algorithm</name>
  <!-- Options : 3des, rc4 -->
  <value>3des</value>
</property>

hadoop.rpc.protection=privacy active le chiffrement complet de tout le trafic RPC. integrity fournit une authentification de message basée sur HMAC sans chiffrement des données. authentication fournit uniquement l'authentification Kerberos sans protection du flux de données.

Chiffrement RPC HBase

Configurer dans hbase-site.xml :

<property>
  <name>hbase.rpc.protection</name>
  <value>privacy</value>
</property>

TLS ZooKeeper

Le TLS client-serveur et quorum ZooKeeper est configuré dans zoo.cfg :

sslQuorum=true
client.secure=true
ssl.keyStore.location=/etc/security/serverKeys/zookeeper.jks
ssl.keyStore.password=<mot-de-passe>
ssl.trustStore.location=/etc/security/serverKeys/zookeeper.truststore.jks
ssl.trustStore.password=<mot-de-passe>

Ambari gère ces paramètres lorsque Auto-TLS est activé.

Chiffrement Ozone

Apache Ozone 2.0.0 supporte le chiffrement au niveau de l'objet via la même infrastructure Ranger KMS utilisée pour le TDE HDFS.

Chiffrement d'un bucket Ozone

# S'authentifier
kinit -kt /etc/security/keytabs/hdfs.headless.keytab hdfs@DEV01.HADOOP.CLEMLAB.COM

# Créer un bucket chiffré en utilisant une clé KMS
ozone sh bucket create \
  --replicationFactor=THREE \
  --type=RATIS \
  -k my-zone-key \
  o3://ozone-host:9862/myvolume/encrypted-bucket

# Vérifier
ozone sh bucket info o3://ozone-host:9862/myvolume/encrypted-bucket
# Chercher : encryptionKeyName: my-zone-key

Tous les objets (clés) écrits dans un bucket Ozone chiffré sont chiffrés avec un DEK dérivé de la clé de zone du bucket, suivant le même schéma de délégation KMS que le TDE HDFS.

Chiffrement en transit Ozone

Ozone utilise TLS pour toute la communication gRPC entre OzoneManager, SCM (Storage Container Manager) et les DataNodes. Configurer via Ambari sous Ozone → Configs → Advanced ozone-site :

ozone.security.enabled=true
hdds.grpc.tls.enabled=true

Lorsque l'Auto-TLS Ambari est actif, ces paramètres sont définis automatiquement.

Chiffrement dans ODP

Chiffrement en transit (TLS)​

Auto-TLS (recommandé)​

Gestion manuelle des certificats​

Chiffrement au repos — HDFS Transparent Data Encryption (TDE)​

Architecture​

Installation et configuration de Ranger KMS​

Création de zones de chiffrement​

Gestion des clés​

Accès aux données chiffrées​

Chiffrement wire pour RPC​

Chiffrement RPC Hadoop​

Chiffrement RPC HBase​

TLS ZooKeeper​

Chiffrement Ozone​

Chiffrement d'un bucket Ozone​

Chiffrement en transit Ozone​