Version: 1.3.1.0

Référence Apache Ranger

Apache Ranger 2.6.0 est la couche d'autorisation centralisée d'ODP. Il fournit un contrôle d'accès fin sur chaque service de données du cluster via une architecture de plugins — sans gestion des ACL au niveau de chaque service.

Architecture de Ranger

┌─────────────────────────────────────────────────────────┐
│                     Ranger Admin                        │
│  (Interface web · API REST · Store de politiques · Audit│
└────────────┬────────────────────────────────────────────┘
             │  Synchronisation des politiques (~30 s)
    ┌────────▼──────────────────────────────────────┐
    │              Plugins Ranger                   │
    │  HDFS · Hive · HBase · Kafka · Knox · YARN   │
    │  Ozone · Impala · NiFi · …                   │
    └────────────────┬──────────────────────────────┘
                     │  Événements d'audit
          ┌──────────▼───────────┐
          │  Backends d'audit    │
          │  Solr  ·  HDFS       │
          └──────────────────────┘

Ranger Admin : Interface web et API REST centrales. Stocke les politiques dans une base de données relationnelle (MySQL/PostgreSQL). Gère la synchronisation utilisateurs/groupes depuis LDAP.
Plugins Ranger : Agents in-process embarqués dans chaque service (NameNode, HiveServer2, HBase Master, etc.). Ils mettent en cache les politiques localement et évaluent les décisions d'accès sans appel réseau vers Admin.
Audit : Chaque décision d'accès (autorisation ou refus) est journalisée dans Solr (pour la recherche et l'interface) et optionnellement dans HDFS (pour la rétention à long terme).

Ranger 2.6.0 dans ODP

Ranger est installé et configuré par Ambari lors du déploiement du cluster. Toute la configuration Ranger (base de données, LDAP, audit, activation des plugins) est gérée via l'interface Ambari sous Services → Ranger.

Éléments clés du déploiement :

Ranger Admin s'exécute sur l'hôte assigné au rôle Ranger Admin dans Ambari.
Le Ranger KMS (Key Management Server) est un service séparé utilisé pour le TDE HDFS — voir Chiffrement dans ODP.
Tous les plugins Ranger sont co-localisés avec leurs daemons de service respectifs.

Configuration de Ranger Admin via Ambari

Naviguer vers Ambari → Services → Ranger → Configs.

Paramètres importants :

Onglet de config	Paramètre clé	Description
Ranger Settings	`ranger_admin_hosts`	Hôte exécutant Ranger Admin
Ranger Settings	`ranger.jpa.jdbc.*`	Connexion à la base de données du store de politiques
Advanced ranger-ugsync-site	`ranger.usersync.ldap.url`	URL LDAP/FreeIPA pour la synchronisation utilisateurs
Advanced ranger-ugsync-site	`ranger.usersync.ldap.binddn`	DN de liaison pour les requêtes LDAP
Ranger Audit	`xasecure.audit.destination.solr`	Activer l'audit Solr
Ranger Audit	`xasecure.audit.destination.hdfs`	Activer l'audit HDFS

Après les modifications dans Ambari, redémarrer Ranger Admin et les services concernés.

Plugins de service

Chaque service de données dispose d'un plugin Ranger dédié. Activer les plugins via Ambari — chaque page de configuration de service a un onglet Ranger Plugin.

Plugin HDFS

Contrôle l'accès aux chemins HDFS. Les politiques peuvent être définies sur des chemins avec des jokers (/data/*). Supporte :

Permissions Lecture / Écriture / Exécution sur les répertoires et fichiers.
Application récursive des politiques.

Ressource : /data/raw/*
Utilisateur : etl_user — Autoriser : Lecture, Écriture
Groupe : analysts — Autoriser : Lecture

Plugin Hive

Contrôle l'accès aux bases de données, tables, colonnes et UDF Hive. Fournit également des politiques de Filtre de lignes et de Masquage de colonnes.

Ressource : database=finance, table=transactions, column=*
Utilisateur : finance_analyst — Autoriser : Select
Masquage de colonne : column=credit_card_number → MASK (afficher les 4 derniers chiffres)

Plugin HBase

Contrôle l'accès aux tables, familles de colonnes et colonnes HBase.

Ressource : table=user_data, column-family=pii, column=*
Utilisateur : app_service — Autoriser : Lecture, Écriture

Plugin Kafka

Contrôle l'accès aux topics Kafka avec les permissions Publish, Consume, Create, Delete, Describe et Idempotent Write.

Ressource : topic=events-*
Utilisateur : kafka_producer — Autoriser : Publish
Groupe : analytics_team — Autoriser : Consume, Describe

Plugin Knox

Contrôle quels utilisateurs et groupes peuvent accéder aux services proxifiés via les topologies Knox.

Ressource : topology=default, service=WEBHDFS
Groupe : external_users — Autoriser : Allow

Plugin Ozone

Contrôle l'accès aux volumes, buckets et clés Ozone.

Ressource : volume=data, bucket=raw, key=*
Utilisateur : ingest_user — Autoriser : Lecture, Écriture, Création, Listage

Plugin YARN

Contrôle l'accès aux files d'attente YARN — quels utilisateurs/groupes peuvent soumettre des jobs dans quelles files.

Ressource : queue=root.production
Groupe : prod_users — Autoriser : Submit Application, Admin Queue

Plugin Impala

Contrôle l'accès aux bases de données, tables, colonnes et UDF Impala — suit le modèle du plugin Hive.

Types de politiques

Politiques d'autorisation (Allow)

Le type de politique par défaut. Accorde un accès explicite aux ressources.

Type de politique : Allow
Ressource : /data/warehouse/hive
Utilisateur : hive — Autoriser : Lecture, Écriture, Exécution

Politiques de refus (Deny)

Refuse explicitement l'accès, surpassant les politiques d'autorisation. À utiliser avec parcimonie — les politiques de refus s'appliquent même aux utilisateurs ayant une politique d'autorisation pour la même ressource.

Type de politique : Deny
Ressource : /data/sensitive/*
Groupe : contractors — Refuser : Lecture, Écriture

Politiques de filtre de lignes (Hive / Impala)

Ajoutent automatiquement une clause WHERE aux requêtes. Transparent pour l'application.

Ressource : database=hr, table=employees
Utilisateur : regional_manager_west
Filtre de lignes : department = 'WEST'

Politiques de masquage de colonnes (Hive / Impala)

Remplacent les valeurs de colonnes sensibles au moment de la requête sans modifier les données stockées.

Type de masquage	Résultat
Redact	`xxxx`
Masque partiel — afficher les 4 derniers	`****1234`
Hash (SHA-256)	`a94f...`
Nullify	`NULL`
Expression personnalisée	Toute expression SQL

Politiques basées sur les tags avec l'intégration Atlas

Les politiques basées sur les tags découplent l'autorisation des noms de ressources — une politique s'applique à toute ressource portant une classification Atlas spécifique, quel que soit son nom ou son emplacement.

Flux de travail

Créer une classification dans Atlas (par exemple, PII, CONFIDENTIEL, RGPD).
Appliquer la classification aux entités Atlas (tables, colonnes, chemins HDFS).
Dans Ranger, créer une politique basée sur les tags ciblant la classification.
La politique s'applique automatiquement à toutes les ressources portant ce tag sur tous les moteurs (Hive, HDFS, HBase, etc.).

Exemple

Politique de tag : classification=PII
Tous les utilisateurs — Refuser : Select
Exception : Groupe=data_stewards — Autoriser : Select
Masquage de colonne pour le tag PII : Hash

Toute colonne Hive, fichier HDFS ou famille de colonnes HBase tagué PII dans Atlas est automatiquement soumis à cette politique sans créer de règles Ranger par ressource.

Configuration de l'audit Ranger

Les enregistrements d'audit capturent : utilisateur, service, ressource, type d'accès, résultat (autorisé/refusé), horodatage et IP client.

Audit Solr (recommandé pour la recherche via l'interface)

Ranger Admin inclut une vue Solr intégrée pour interroger les journaux d'audit. Configurer dans Ambari sous Ranger → Ranger Audit :

xasecure.audit.destination.solr = true
xasecure.audit.destination.solr.urls = http://ranger-solr-host:8983/solr/ranger_audits

Audit HDFS (rétention à long terme)

xasecure.audit.destination.hdfs = true
xasecure.audit.destination.hdfs.dir = hdfs:///ranger/audit

Les fichiers d'audit sont stockés en JSON lines, partitionnés par service et date :

/ranger/audit/hdfs/20260408/hdfs_audit_20260408_000000.log.gz

Aperçu de l'API REST Ranger

Ranger Admin expose une API REST pour la gestion programmatique des politiques.

Authentification

# Auth basique (ou Kerberos negotiate si le cluster est sécurisé)
RANGER_URL="https://ranger-admin-host:6182"
AUTH="-u admin:ranger-admin-password"

Lister les politiques d'un service

curl -s $AUTH "$RANGER_URL/service/public/v2/api/policy?serviceName=hdp_hdfs" | python3 -m json.tool

Créer une politique

curl -s -X POST $AUTH \
  -H "Content-Type: application/json" \
  -d '{
    "name": "etl-raw-access",
    "service": "hdp_hdfs",
    "resources": {
      "path": {"values": ["/data/raw"], "isRecursive": true}
    },
    "policyItems": [{
      "users": ["etl_user"],
      "accesses": [{"type": "read"}, {"type": "write"}],
      "isAuditEnabled": true
    }],
    "isEnabled": true
  }' \
  "$RANGER_URL/service/public/v2/api/policy"

Mettre à jour une politique

curl -s -X PUT $AUTH \
  -H "Content-Type: application/json" \
  -d '<json-politique-mise-a-jour>' \
  "$RANGER_URL/service/public/v2/api/policy/<id-politique>"

Supprimer une politique

curl -s -X DELETE $AUTH "$RANGER_URL/service/public/v2/api/policy/<id-politique>"

Synchronisation des utilisateurs et groupes depuis LDAP / FreeIPA

Ranger User Sync (ranger-usersync) importe périodiquement les utilisateurs et groupes depuis LDAP afin que les politiques Ranger puissent référencer directement les noms de groupes LDAP.

Configurer dans Ambari sous Ranger → Advanced ranger-ugsync-site :

ranger.usersync.enabled = true
ranger.usersync.source.impl.class = org.apache.ranger.ldapusersync.process.LdapUserGroupBuilder

# FreeIPA / 389-DS
ranger.usersync.ldap.url = ldap://ipa01.dev01.hadoop.clemlab.com:389
ranger.usersync.ldap.binddn = uid=ranger-sync,cn=users,cn=accounts,dc=dev01,dc=hadoop,dc=clemlab,dc=com
ranger.usersync.ldap.ldapbindpassword = <mot-de-passe-sync>
ranger.usersync.ldap.user.searchbase = cn=users,cn=accounts,dc=dev01,dc=hadoop,dc=clemlab,dc=com
ranger.usersync.ldap.user.objectclass = person
ranger.usersync.ldap.user.nameattribute = uid
ranger.usersync.ldap.group.searchbase = cn=groups,cn=accounts,dc=dev01,dc=hadoop,dc=clemlab,dc=com
ranger.usersync.ldap.group.objectclass = groupofnames
ranger.usersync.ldap.group.nameattribute = cn
ranger.usersync.ldap.group.memberattributename = member

# Intervalle de synchronisation (millisecondes)
ranger.usersync.sleeptimeinmillisbetweensynccycle = 60000

Après la configuration, redémarrer Ranger UserSync depuis Ambari. Les utilisateurs et groupes apparaissent dans l'interface Ranger Admin sous Settings → Users/Groups.

Référence Apache Ranger

Architecture de Ranger​

Ranger 2.6.0 dans ODP​

Configuration de Ranger Admin via Ambari​

Plugins de service​

Plugin HDFS​

Plugin Hive​

Plugin HBase​

Plugin Kafka​

Plugin Knox​

Plugin Ozone​

Plugin YARN​

Plugin Impala​

Types de politiques​

Politiques d'autorisation (Allow)​

Politiques de refus (Deny)​

Politiques de filtre de lignes (Hive / Impala)​

Politiques de masquage de colonnes (Hive / Impala)​

Politiques basées sur les tags avec l'intégration Atlas​

Flux de travail​

Exemple​

Configuration de l'audit Ranger​

Audit Solr (recommandé pour la recherche via l'interface)​

Audit HDFS (rétention à long terme)​

Aperçu de l'API REST Ranger​

Authentification​

Lister les politiques d'un service​

Créer une politique​

Mettre à jour une politique​

Supprimer une politique​

Synchronisation des utilisateurs et groupes depuis LDAP / FreeIPA​