Vue d'ensemble de la sécurité ODP

La sécurité dans ODP repose sur un modèle de défense en profondeur : plusieurs couches indépendantes appliquent chacune leurs propres contrôles, de sorte qu'une défaillance ou un contournement à un niveau n'expose pas les données. ODP intègre Kerberos, Apache Ranger, Apache Knox et le chiffrement TLS dans une architecture de sécurité cohérente qu'Ambari automatise de bout en bout.

Architecture de défense en profondeur

Clients externes
      │
   Apache Knox (passerelle périmétrique, terminaison TLS, SSO)
      │
   Apache Ranger (autorisation : RBAC, ABAC, basé sur les tags, filtrage lignes/colonnes)
      │
   Kerberos (authentification : chaque service, chaque appel RPC)
      │
   TLS / chiffrement du flux (chiffrement en transit entre tous les nœuds)
      │
   Zones de chiffrement HDFS (chiffrement au repos pour les données sensibles)

Chaque couche adresse un vecteur de menace différent. Ensemble, elles satisfont les exigences de sécurité des environnements réglementés (RGPD, NIS2, référentiels de conformité internes).

Authentification Kerberos

Kerberos constitue l'épine dorsale de l'authentification dans ODP. Lorsqu'il est activé (configuration par défaut en production), chaque communication service-à-service et client-à-service est authentifiée via des tickets Kerberos. Aucun composant n'accepte de connexions non authentifiées.

Fonctionnement dans ODP

• Chaque service Hadoop (NameNode, DataNode, ResourceManager, HiveServer2, brokers Kafka, HBase, etc.) obtient un principal de service auprès du Centre de Distribution de Clés (KDC).
• Les clients s'authentifient auprès du KDC avec leur principal utilisateur (via kinit ou un keytab) et reçoivent un Ticket Granting Ticket (TGT).
• Lorsqu'un client se connecte à un service, il présente un ticket de service obtenu à partir du TGT — aucun mot de passe ne transite sur le réseau.
• L'usurpation d'identité de service (agir au nom d'un utilisateur) utilise la délégation contrainte, empêchant les mouvements latéraux si un service est compromis.

Intégration avec FreeIPA

ODP s'intègre à FreeIPA en tant que KDC et fournisseur d'identité LDAP. FreeIPA offre :

• Gestion centralisée des utilisateurs et groupes via une interface web
• Provisionnement automatique des principals pour les services Hadoop
• Découverte de services basée sur DNS
• Gestion des certificats pour TLS

L'assistant Kerberos d'Ambari prend en charge FreeIPA nativement : il automatise la création des principals, la génération et la distribution des keytabs sur tous les nœuds, et la mise à jour de la configuration de tous les composants ODP.

MIT KDC et Active Directory

Pour les environnements sans FreeIPA, ODP prend également en charge MIT KDC (autonome) et Active Directory (via des trusts inter-royaumes ou une intégration AD directe) comme fournisseurs Kerberos.

Apache Ranger — Autorisation

Apache Ranger fournit une autorisation centralisée et fine pour tous les services ODP. Les politiques Ranger sont définies une fois dans l'interface d'administration Ranger et appliquées par des plugins légers s'exécutant au sein de chaque service.

Modèles de politiques

Contrôle d'accès basé sur les rôles (RBAC) : les politiques accordent ou refusent l'accès aux ressources (chemins HDFS, bases de données/tables/colonnes Hive, topics Kafka, tables HBase) en fonction des utilisateurs et des groupes.

Contrôle d'accès basé sur les attributs (ABAC) : les politiques peuvent inclure des conditions sur les attributs de la requête (heure de la journée, plage d'adresses IP, application cliente) pour implémenter des règles d'accès contextuelles.

Politiques basées sur les tags : Ranger s'intègre à Apache Atlas. Lorsqu'Atlas classe une colonne avec un tag tel que PII ou SENSITIVE, Ranger applique automatiquement des politiques de masquage ou de refus à cette colonne dans tous les moteurs — sans que l'auteur de la politique ait besoin de connaître les tables contenant des données sensibles.

Filtrage au niveau des lignes et des colonnes

Ranger prend en charge :

• Masquage de colonnes : remplacer les valeurs réelles par des représentations masquées (nullification, hachage, masquage partiel) pour les utilisateurs non autorisés — la colonne reste visible dans les résultats de requête mais les données sont cachées.
• Filtrage au niveau des lignes : ajouter de façon transparente une clause WHERE aux requêtes, de sorte que les utilisateurs ne voient que les lignes correspondant à leur contexte d'autorisation.

Ces capacités permettent un accès en libre-service aux jeux de données de production sans exposer les enregistrements sensibles.

Audit Ranger

Chaque tentative d'accès (accordée ou refusée) est consignée dans la piste d'audit Ranger, qui peut être écrite dans HDFS, Solr ou un SIEM externe. Le journal d'audit enregistre l'identité de l'utilisateur, la ressource accédée, l'action effectuée, la politique appliquée et le résultat — fournissant les preuves nécessaires pour les rapports de conformité.

Apache Knox — Passerelle périmétrique

Apache Knox joue le rôle de point d'entrée unique pour l'accès externe aux services du cluster ODP. Aucun port interne de service n'a besoin d'être exposé aux clients situés en dehors du réseau du cluster.

Proxy REST

Knox traduit les requêtes HTTPS des clients externes en requêtes authentifiées par Kerberos vers les services internes :

• HDFS WebHDFS
• API REST du ResourceManager YARN
• HiveServer2 (via JDBC-over-HTTPS)
• Passerelle REST HBase
• API REST Ambari

SSO et fédération d'identité

Knox s'intègre aux fournisseurs d'identité externes via SAML 2.0 et OAuth 2.0/OIDC, permettant l'authentification unique (SSO) pour les interfaces web (Ambari, Zeppelin, Ranger Admin). Les utilisateurs s'authentifient une seule fois auprès de leur IdP d'entreprise et reçoivent un token Knox qui leur donne accès à tous les services du cluster autorisés.

Le support OIDC est en cours d'extension dans ODP 1.3.2.0 pour couvrir des services supplémentaires et les flux d'authentification machine-à-machine basés sur les tokens.

Chiffrement

Chiffrement en transit

Toutes les communications inter-nœuds dans ODP utilisent TLS 1.2+ :

• Protocole de transfert de données HDFS (DataNode-à-DataNode, client-à-DataNode)
• RPC YARN
• Connexions JDBC HiveServer2
• Communications broker-à-broker et client-à-broker Kafka
• HBase, ZooKeeper et tous les services gérés par Ambari

Les certificats TLS sont émis et gérés par l'autorité de certification intégrée de FreeIPA lorsque FreeIPA est le KDC.

Chiffrement au repos

Le Transparent Data Encryption (TDE) HDFS chiffre les données au niveau des blocs à l'aide de zones de chiffrement. Une zone de chiffrement est une sous-arborescence HDFS où tous les fichiers sont automatiquement chiffrés avec une clé de zone gérée par le Hadoop Key Management Server (KMS). Les applications lisent et écrivent les données de façon transparente — le chiffrement/déchiffrement s'effectue dans le client HDFS avant que les données soient envoyées aux DataNodes ou reçues de ceux-ci.

Automatisation de la sécurité par Ambari

La sécurisation manuelle d'un cluster Hadoop est complexe et sujette aux erreurs. Ambari dans ODP automatise l'intégralité de la configuration de sécurité :

• Assistant Kerberos : un workflow guidé dans Ambari qui collecte les identifiants KDC et automatise la création des principals, la distribution des keytabs et la reconfiguration des services sur tous les nœuds du cluster pour chaque composant ODP.
• Auto-configuration des plugins Ranger : lorsque Ranger est activé dans Ambari, il installe et configure automatiquement le plugin Ranger pour chaque service supporté (HDFS, Hive, HBase, Kafka, Knox, Atlas, YARN) et crée des politiques par défaut de type "tout refuser" que les administrateurs affinent ensuite.
• Auto-configuration TLS : Ambari peut générer et distribuer des certificats TLS pour tous les services via l'AC du cluster, permettant des communications chiffrées sans gestion manuelle des certificats.

Support OIDC (à venir dans ODP 1.3.2.0)

ODP 1.3.2.0 étendra le support OIDC (OpenID Connect) pour permettre des flux d'authentification basés sur les tokens pour :

• Les interfaces web modernes et les clients API REST qui préfèrent les bearer tokens aux tickets Kerberos
• L'authentification machine-à-machine pour les pipelines automatisés
• L'intégration avec les IdPs d'entreprise (Keycloak, Azure AD, Okta) sans nécessiter un trust Kerberos inter-royaumes

Les tokens OIDC seront validés par Knox et échangés en interne contre des tickets de service Kerberos, maintenant ainsi la compatibilité ascendante avec les services backend sécurisés par Kerberos.