Gestion des identités utilisateurs sur clusters Big Data

La sécurisation d’un cluster Big Data implique l’intégration ou le déploiement de services spécifiques pour stocker les utilisateurs. Certains utilisateurs sont spécifiques à un cluster lorsque d’autres sont partagés entre tous les clusters. Il n’est pas toujours clair de savoir comment ces différents services s’articulent et s’ils doivent être partagés entre plusieurs clusters. Aussi, quelle stratégie prendre et quels sont ses impacts s’il est envisagé de migrer à une date ultérieure la connaissance des utilisateurs depuis un service local vers un Active Directory ou un FreeIPA déjà présent dans la société.

Authentification et identification

Hadoop repose sur le protocole Kerberos pour l’authentification. L’authentification consiste à valider qu’un utilisateur est bien la personne qu’elle prétend être. Par exemple, si je soumets une requête à un système, le rôle de l’authentification n’est pas de valider que j’ai la permission de soumettre cette requête mais de seulement confirmer que je suis bien moi. Dans le cadre de Kerberos, l’identité d’un utilisateur est définie par un principal. Ce principal est rattaché à un domaine et peut prendre deux formes : {username}@{realm} et {username}/{fqdn}@{realm}. La seconde forme reprend la première et y incorpore le nom de domain complet de la machine hôte. Elle s’applique à des utilisateurs systèmes installés sur un noeud. Par exemple un composant my_app installé sur le noeud node_1.cluster_01.company.com pourrait recevoir un nom de principal my_app/node_01.cluster_01.company.com@CLUSTERT01_COMPANY. Ce type de principal est utilisé par des systèmes utilisant Kerberos pour authentifier les services qui le composent en plus des utilisateurs externes qui y accèdent. Pour s’authentifier avec Kerberos, il existe deux mécanismes : par mot de passe et par keytab. Une keytab est un fichier qui est uniquement accessible à un utilisateur. L’utilisation de ce fichier évite l’utilisation d’un mot de passe. L’inconvénient est que tout autre individu ayant accès à la keytab d’un autre pourra voler son identité. Dans cette éventualité, une keytab est associée à un numéro unique. Ainsi, la génération pour un principal donné d’une nouvelle keytab invalide les keytabs précédentes.

Une fois authentifiés, les utilisateurs doivent être connus par le système d’exploitation sous-jacent. L’identification consiste à associer à un utilisateur des propriétés. Hadoop délègue au système la connaissance des utilisateurs et leurs appartenances à différents groupes. La connaissance d’un utilisateur dans Linux implique l’existence d’un uid associé à chaque utilisateur et d’un gid associé à chaque groupe. Par exemple, lorsque YARN lance un job Spark, les fichiers nécessaires à ce job (jar, configuration, …) sont déposés sur chacun des noeuds exécutant ce job avec les permissions de l’utilisateur ayant soumis le job. Dans la mesure où les composants Big Data sont distribués sur plusieurs noeuds pour former un cluster, il est impératif que la configuration soit homogène à l’ensemble du cluster. Par défaut, Linux stocke ses utilisateurs dans le fichier /etc/passwd mais il est possible de pointer le système sur une base de données déportées, traditionnellement un annuaire LDAP. Sur RHEL et CentOS, la manière la plus simple de configurer le système ainsi est de configurer le service SSSD.

La traduction d’un principal en nom d’utilisateur se fait par un ensemble de règles présentes dans la propriété auth-to-local. Il est par exemple possible d’y définir une règle qui traduit le principal hdfs@CLUSTER01_COMPANY et le principal data_node/worker_01.cluster_01.company.com@CLUSTER01_COMPANY en identité hdfs.

L’authentification reposent sur un serveur Kerberos et l’identification utilise généralement un server LDAP. Les trois solutions les plus communes sont :

• MIT Kerberos + OpenLDAP
• FreeIPA
• Active Directory (AD)

Les différents types d’utilisateurs

On distingue 3 types d’utilisateurs que nous définissons ainsi chez Adaltas :

• les utilisateurs de services
• les utilisateurs applicatifs
• les utilisateurs nominatifs

Utilisateurs de services

Un service Linux est une application exécutée en tant que tâche de fond par le système. Pour éviter de stocker des mots de passe en clair sur le système, les principals des composants Hadoop n’ont pas de mot de passe connu mais seulement une keytab. Ils sont déclarés dans Kerberos sous la forme {username}/{fqdn}@{domain}. Ainsi, chaque composant est authentifié par une keytab unique. Il est aussi possible de créer des utilisateurs sous la forme plus classique {username}@{domain}. Par exemple, pour des raisons de confort, il est commun de créer un principal hdfs@MY_HADOOP_DOMAIN pour permettre aux administrateurs du cluster de bénéficier de permissions étendues sur le système de fichier.

Les utilisateurs de services ne sont connus qu’à l’intérieur d’un cluster. Il est donc adapté de les cloisonner dans un domaine Kerberos dédié à ce cluster. On garantit ainsi simplement l’étanchéité du cluster envers d’autres composants configurés en dehors. De plus, les utilisateurs créés ne risquent pas d’entrer en conflit avec ceux d’un autre cluster portant le même nom comme cela serait le cas dans l’exemple du principal hdfs@MY_HADOOP_DOMAIN cité précédemment.

Il existe des solutions de contournement mais pour faire simple, à chaque cluster Hadoop doit être associé un domaine Kerberos unique.

L’identité de l’utilisateur n’a pas besoin d’être déléguée à un système externe centralisant sa gestion. Ses informations ne seront pas mises à jour et seul son uid et son gid sont utilisés. Il n’y a pas de groupes associés à cet utilisateur, autres que ceux déclarés à l’installation du service. Pour ces raisons, on privilégie le mécanisme interne au système, basé sur POSIX et le fichier /etc/passwd.

La seule précaution à prendre est de s’assurer que les uid et gid provisionnés par le système ne rentrent pas en conflit avec ceux du LDAP de l’entreprise. Pour cela, il est nécessaire de soit configurer le système pour utiliser une plage compatible avec celles en usage dans l’entreprise, soit utiliser un outil de provisionnement (Ansible, Nikita, …) pour contrôler les uid et gid générés.

Utilisateurs applicatifs

Les utilisateurs applicatifs sont associés à un projet, une application ou un ensemble de processus. Ils sont théoriquement les seuls à pouvoir lancer des jobs sur un cluster de production. Cette règle s’assouplit en fonction de la taille du cluster, de son rôle dans l’organisation, la sensibilité des données et de la criticité des SLAs qu’il honore.

Au lancement d’un nouveau cluster Big Data dans une organisation, il est commun que celui-ci soit à la fois considéré comme cluster de production, de pré-production et même de développement. A mesure que l’usage du Big Data se développe et mature, de nouveaux clusters sont amenés à le compléter. Les applications critiques hébergées, tant en terme de sensibilité des données et que des impacts opérationnels en cas d’interruption de service, peuvent imposer que seuls des utilisateurs “qualifiés” soient en charge de l’exécution des traitements. A ce stade, les développeurs utiliseront un cluster dédié au développement. Aussi, les utilisateurs et les applications consommatrices de données avec des traitements ad-hoc seront déplacés vers un cluster ou un espace dédié à leurs usages, communément appelé Data Lab.

Si le cluster endosse les rôles de Data Lake et de Data Lab, il n’est pas aberrant d’ouvrir l’accès à des Data Analysts et des Data Scientists pour consommer les données. Dans ce cas, l’accent doit être mis sur le paramétrage multi-tenant du cluster, par exemple en garantissant un bon partage des ressources allouées et une sélection de composants en mesure de garantir ce partage de ressources. En s’appuyant sur le tiering HDFS et les labels de YARN, Adaltas a aussi déployé des clusters qui isolent leurs usages en deux espaces distincts d’un même cluster, l’un dédié à la gestion du Data Lake et l’autre à son utilisation par des Data Analysts et des Data Scientists.

Les identités des utilisateurs applicatifs sont habituellement partagées entre les différents clusters. Par exemple un utilisateur au nom d’une application doit exister sur les clusters de production, de pré-production, de qualification et même de développement. Il n’est pas toujours désirable de partager l’authentification des utilisateurs applicatifs. Une keytab, ou mot-de-passe, sera valide depuis tous les clusters référencent un même serveur Kerberos, ce qui n’est pas toujours souhaitable et doît être architecturé conjointement avec l’appartenance des utilisateurs à des groupes. Pour ce type d’utilisateur, la recommandation est donc de stocker les identités des utilisateurs dans un LDAP partagé et d’utiliser un serveur Kerberos dédié à chaque cluster. En général, il n’y a pas une utilisation intensive des groupes d’utilisateurs mais si c’est le cas, il est aussi préférable de la maintenir à l’échelle d’un cluster.

Les utilisateurs nominatifs

Les utilisateurs nominatifs sont associés à une personne physique. Il existe plusieurs profils d’utilisateurs. Certains interagissant directement avec le système, d’autres au travers d’une application. Certains ont besoin de données finies qui ont été préparées et mises à disposition, d’autres de tout type de données dont des données brutes.

Ainsi, les Data Analysts consomment souvent la donnée par l’intermédiaire d’outils orientés analyse. Ils créent et consomment des tableaux de bord plus ou moins dynamiques ainsi que des indicateurs à valeur ajoutée. Les Data Scientists ont eux besoin de la donnée à tous les niveaux de son cycle de vie pour l’explorer et produire de nouveaux indicateurs, réductions ou encore prédictions.

L’identité des utilisateurs nominatifs et leur mécanisme d’authentification est déjà présente dans la plupart des organisations, souvent déléguée à un Active Directory ou FreeIPA. Il est recommandé d’intégrer le cluster aux services déjà présents dans l’entreprise et le plus tôt possible. Cette centralisation permet une seule gestion des mots de passe et la garantie de l’inaccessibilité des utilisateurs non actifs. L’assignation d’un utilisateur à un groupe peut être soit gérée par une autorité centrale soit par un service rattaché au cluster. Dans les deux cas, il est recommandé qu’elle soit spécifique à chaque cluster. Une même personne peut être membre d’un groupe sur un cluster mais pas sur une autre.

Migration des utilisateurs nominatifs

Dans l’éventualité où il serait envisagé de migrer vers l’annuaire de l’entreprise et où cette action serait impossible à réaliser dans l’immédiat, il est relativement aisé d’anticiper cette action. Le seul impératif est de conserver les même noms d’utilisateur entre l’ancien et le nouveau système. Grâce au mécanisme auth-to-local, deux principals Kerberos seront traduits par le même username.

Le processus sera simple et presque transparent pour les utilisateurs finaux. La seule action qu’ils auront à réaliser sera d’utiliser une nouvelle keytab s’ils en font l’usage ou d’abandonner leur mot de passe spécifique au cluster au profit de leur mot de passe habituel. Ce mot de passe est sans doute le même que celui utilisé pour se logger sur le poste de travail.

L’administrateur de la plateforme devrait mettre à jour l’ensemble des fichiers clients Kerberos pour définir le nouveau domaine et ajouter une règle de traduction à la propriété auth-to-local pour prendre en compte le nouveau domaine.

Conclusion

Comme souvent, il est recommandé de commencer simple et de commencer petit. Afin de pérenniser l’évolution de la plateforme, il est possible de complexifier l’architecture en introduisant de nouveaux services et en s’intégrant à des services existants.