Lac de données kerberisé sur Dataproc

Last reviewed 2024-04-16 UTC

Ce document décrit les concepts, les bonnes pratiques et l'architecture de référence pour la mise en réseau, l'authentification et l'autorisation d'un lac de données kerberisé sur Google Cloud à l'aide du centre de distribution de clés (KDC, Key Distribution Center) sur cluster de Dataproc et d'Apache Ranger. Dataproc est le service géré de Google Cloud pour Hadoop et Spark. Ce document est destiné aux administrateurs Apache Hadoop, aux architectes cloud et aux équipes de big data qui migrent leurs clusters Hadoop et Spark traditionnels vers un lac de données moderne fourni par Dataproc.

Un lac de données kerberisé sur Google Cloud aide les entreprises qui disposent de déploiements hybrides et multi-cloud à exploiter et développer leurs investissements informatiques existants pour la gestion des identités et des contrôles d'accès.

Sur Google Cloud, les entreprises peuvent fournir à leurs équipes autant de clusters éphémères associés à une tâche que nécessaire. Cette approche réduit fortement la complexité liée à la maintenance d'un cluster unique avec des dépendances et des interactions de configuration logicielles de plus en plus nombreuses. Les organisations peuvent également choisir de créer des clusters plus durables pour que plusieurs utilisateurs et services puissent y accéder. Le présent document explique comment utiliser des outils standards de l'industrie, tels que Kerberos et Apache Ranger, pour garantir une sécurité utilisateur précise (authentification, autorisation et audit) pour ces deux types de clusters sur Dataproc.

Cas d'utilisation client

Certaines entreprises migrent leurs lacs de données sur site basés sur Hadoop vers des plates-formes cloud publiques afin de résoudre les problèmes de gestion des clusters traditionnels.

L'une de ces entreprises, un grand leader technologique dans le domaine des logiciels et du matériel informatique d'entreprise, a décidé de migrer son système Hadoop sur site vers Google Cloud. Son environnement Hadoop sur site était utilisé pour répondre aux besoins d'analyse de centaines d'équipes et d'unités commerciales, y compris une équipe de cybersécurité comptant pas moins de 200 membres qui travaillent à l'analyse des données. Lorsqu'un membre de l'équipe exécutait une requête volumineuse avec l'ancien lac de données, il rencontrait des problèmes en raison du caractère rigide de ses ressources. Comme l'entreprise avait du mal à répondre aux besoins d'analyse de l'équipe avec son environnement sur site, elle a choisi de migrer vers Google Cloud. En passant à Google Cloud, l'entreprise a pu réduire de 25 % le nombre de problèmes signalés sur son lac de données sur site.

Le plan de migration vers Google Cloud de l'entreprise consistait essentiellement à remodeler et optimiser les grands clusters monolithiques en se basant sur les charges de travail des équipes afin de se concentrer sur la génération de valeur commerciale plutôt que sur la gestion des clusters. Les quelques grands clusters ont été divisés en clusters Dataproc plus petits et économiques, tandis que les charges de travail et les équipes ont été migrés vers les types de modèles suivants :

  • Clusters éphémères associés à une tâche : en seulement quelques minutes, le modèle éphémère permet à une tâche ou à un workflow de disposer d'un cluster dédié qui sera arrêté une fois la tâche déterminée. Ce modèle dissocie le stockage des nœuds de calcul en remplaçant le système de fichiers distribué Hadoop (HDFS, Hadoop Distributed File System) par Cloud Storage, à l'aide du connecteur Cloud Storage intégré à Dataproc. pour Hadoop.
  • Clusters semi-durables : si les clusters éphémères associés à une tâche ne sont pas adaptés pour un cas d'utilisation donné, les clusters Dataproc peuvent être utilisés de façon plus durable. Le cluster peut être arrêté une fois les données avec état déchargées dans Cloud Storage, c'est pourquoi on parle de cluster semi-durable. L'autoscaling intelligent des clusters permet de démarrer avec un petit cluster et d'optimiser les ressources de calcul pour des applications spécifiques. Cet autoscaling remplace la gestion des files d'attente YARN.

Défi posé par la sécurité hybride

Dans le scénario client précédent, le client a migré un système de gestion de données conséquent vers le cloud. Cependant, d'autres parties du système informatique de l'organisation devaient rester sur site (par exemple, certains des anciens systèmes qui alimentent le lac de données).

L'architecture de sécurité doit garantir que le fournisseur d'identité (IdP) centralisé sur site (basé sur LDAP) reste la source faisant autorité pour les identités d'entreprise qui utilisent le lac de données. La sécurité Hadoop sur site est basée sur Kerberos et LDAP pour l'authentification (souvent dans le cadre du service Active Directory (AD) de Microsoft) et sur plusieurs autres logiciels Open Source (OSS) comme Apache Ranger. Cette approche de sécurité permet d'authentifier et d'auditer précisément les activités des utilisateurs et des équipes dans les clusters de lacs de données. Sur Google Cloud, la gestion de l'authentification et des accès (IAM) permet de gérer l'accès à des ressources Google Cloud spécifiques telles que Dataproc et Cloud Storage.

Le présent document traite d'une approche de sécurité qui tire parti du meilleur de la sécurité sur site avec OSS Hadoop (en mettant l'accent sur Kerberos, le LDAP d'entreprise et Apache Ranger) et d'IAM afin de sécuriser les charges de travail et les données à l'intérieur et à l'extérieur des clusters Hadoop.

Architecture

Le schéma suivant illustre l'architecture générale :

Architecture de haut niveau d'un lac de données kerberisé sur Google Cloud à l'aide de Dataproc.

Dans le diagramme précédent, les clients exécutent des tâches sur des clusters multi-équipes ou à équipe unique. Les clusters utilisent un métastore Hive central ainsi que l'authentification Kerberos avec un fournisseur d'identité d'entreprise.

Composants

L'architecture propose de combiner des outils Open Source standards de l'industrie avec IAM pour authentifier et autoriser les différentes manières d'envoyer des tâches, qui vous seront présentées plus loin dans le présent document. Voici les principaux composants qui sont conjointement utilisés pour sécuriser de manière précise les charges de travail des équipes et des utilisateurs dans les clusters Hadoop :

  • Kerberos : Kerberos est un protocole d'authentification réseau qui utilise la cryptographie à clé secrète pour fournir une authentification forte aux applications clientes/serveurs. Le serveur Kerberos est appelé centre de distribution de clés (KDC, Key Distribution Center).

    Kerberos est largement utilisé dans les systèmes sur site tels que AD pour authentifier les utilisateurs, les services et les machines (les entités clientes sont désignées comme des comptes principaux d'utilisateur). L'activation de Kerberos sur Dataproc utilise la distribution MIT gratuite de Kerberos pour créer un KDC sur cluster. Le KDC sur cluster de Dataproc diffuse les requêtes des comptes principaux d'utilisateur pour l'accès aux ressources du cluster, comme Apache Hadoop YARN, HDFS ou Apache Spark (les ressources de serveur sont appelées comptes principaux de service). L'approbation de domaine croisé Kerberos vous permet de connecter les comptes principaux d'utilisateur d'un domaine à un autre.

  • Apache Ranger : Apache Ranger fournit aux utilisateurs des autorisations précises pour effectuer des actions spécifiques sur les services Hadoop. Il audite également l'accès des utilisateurs et met en œuvre des actions administratives. Ranger peut se synchroniser avec un serveur LDAP d'entreprise sur site ou avec AD pour obtenir les identités des utilisateurs et des services.

  • Metastore Hive partagé : le métastore Hive est un service qui stocke les métadonnées pour Apache Hive et d'autres outils Hadoop. Étant donné qu'un grand nombre de ces outils sont construits autour du métastore Hive, ce dernier est devenu un composant essentiel de nombreux lacs de données. Dans l'architecture proposée, un métastore Hive centralisé et kerberisé permet à plusieurs clusters de partager des métadonnées de manière sécurisée.

Kerberos, Ranger et le métastore Hive partagé travaillent ensemble pour sécuriser l'activité des utilisateurs dans les clusters Hadoop, tandis qu'IAM contrôle l'accès aux ressources Google Cloud. Par exemple, Dataproc utilise le compte de service Dataproc pour effectuer des opérations de lecture et d'écriture sur des buckets Cloud Storage.

Dimensions de cluster

Les dimensions suivantes caractérisent un cluster Dataproc :

  • Location : un cluster est multilocataire s'il répond aux requêtes de plusieurs utilisateurs ou services, ou à locataire unique s'il traite les requêtes d'un seul utilisateur ou service.
  • Kerberos : un cluster peut être kerberisé si vous activez Kerberos sur Dataproc ou non-kerberisé si vous n'activez pas Kerberos sur Dataproc.
  • Cycle de vie : un cluster est éphémère s'il n'est créé que pour la durée d'une tâche ou d'un workflow spécifique. Il ne contient que les ressources nécessaires pour exécuter la tâche et il est arrêté à l'issue de la tâche. Sinon, le cluster est considéré comme semi-durable.

Les différentes combinaisons de ces dimensions déterminent les cas d'utilisation pour lesquels un cluster spécifique est adapté. Ce document traite des exemples représentatifs suivants :

  1. Les exemples de clusters multi-équipes présentés dans l'architecture sont des clusters kerberisés, multilocataires et semi-durables. Ces clusters conviennent particulièrement aux charges de travail de requêtes interactives et peuvent par exemple être dédiés à l'analyse de données à long terme ou à l'exploration d'informatique décisionnelle (BI). Dans l'architecture, les clusters se trouvent dans un projet Google Cloud partagé par plusieurs équipes et sont utilisés pouur traiter les requêtes de ces équipes, d'où leur nom.

    Dans le présent document, le terme équipe ou équipe de développement désigne, dans une entreprise, un groupe de personnes travaillant sur le même composant logiciel ou agissant en tant qu'équipe fonctionnelle. Par exemple, une équipe peut faire référence à des développeurs backend pour un microservice, à des analystes BI pour une application métier ou même à des équipes pluridisciplinaires comme celles en charge de l'infrastructure Big Data.

  2. Les exemples de clusters à équipe unique présentés dans l'architecture peuvent être des clusters multilocataire (pour les membres d'une même équipe) ou à locataire unique.

  • En tant que clusters éphémères, ces clusters peuvent être utilisés par des ingénieurs de données pour exécuter des tâches de traitement par lot avec Spark ou par des data scientists pour une tâche d'entraînement de modèle.
  • En tant que clusters semi-durables, les clusters à équipe unique peuvent diffuser des charges de travail d'analyse de données et de BI pour une seule équipe ou pour une seule personne.

    Les clusters à équipe unique sont situés dans des projets Google Cloud appartenant à une seule équipe, ce qui simplifie l'audit d'utilisation, la facturation et l'isolation des ressources. Par exemple, seuls les membres de l'équipe peuvent accéder aux buckets Cloud Storage utilisés pour conserver les données du cluster. Dans cette approche, les équipes de développement utilisent des projets dédiés. Par conséquent, les clusters à équipe unique ne sont pas kerberisés.

Nous vous recommandons d'analyser vos exigences spécifiques et de choisir la combinaison de dimensions la mieux adaptée à votre situation.

Envoyer des tâches

Les utilisateurs peuvent envoyer des tâches aux deux types de clusters à l'aide de divers outils qui incluent notamment :