Lac de données kerberisé sur Dataproc

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 :

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 :

• L'API Dataproc, en utilisant des appels REST ou des bibliothèques clientes.
• L'outil de ligne de commande gcloud de Google Cloud CLI depuis une fenêtre de terminal locale ou depuis Google Cloud Console en utilisant Cloud Shell dans un navigateur.
• Un modèle de workflow Dataproc, c'est-à-dire une configuration de workflow réutilisable qui définit un graphe des tâches avec des informations sur leur emplacement d'exécution. Si le workflow utilise l'option de cluster géré, il utilisera un cluster éphémère.
• Cloud Composer, à l'aide de l'opérateur Dataproc. Les graphes orientés acycliques (DAG) dirigés par Composer peuvent également être utilisés pour orchestrer des modèles de workflow Dataproc.
• L'ouverture d'une session SSH dans le nœud maître du cluster pour envoyer une tâche directement ou à l'aide d'outils comme Apache Beeline. Cet outil est généralement réservé aux administrateurs et aux utilisateurs expérimentés. Un utilisateur expérimenté peut être un développeur qui souhaite dépanner les paramètres de configuration d'un service et les vérifier en exécutant des tâches de test directement sur le nœud maître.

Mise en réseau

Le schéma suivant illustre les concepts de mise en réseau de l'architecture :

Dans le schéma précédent, l'architecture réseau utilise un modèle de maillage hybride dans lequel certaines ressources sont situées sur Google Cloud et d'autres sur site. Le modèle de maillage hybride utilise un VPC partagé avec un projet hôte commun et des projets distincts pour chaque type de cluster et chaque équipe Dataproc. L'architecture est décrite en détail dans les sections Sur Google Cloud et Sur site ci-après.

Sur Google Cloud

Sur Google Cloud, l'architecture est structurée à l'aide d'un VPC partagé. Un VPC partagé permet aux ressources de plusieurs projets de se connecter à un réseau VPC commun. L'utilisation d'un réseau VPC commun permet aux ressources de communiquer entre elles de manière sécurisée et efficace en utilisant des adresses IP internes de ce réseau. Pour configurer un VPC partagé, créez les projets suivants :

• Projet hôte : le projet hôte contient un ou plusieurs réseaux VPC partagés utilisés par tous les projets de service.

• Projets de service : un projet de service contient des ressources Google Cloud associées. Un administrateur de VPC partagé associe les projets de service au projet hôte afin de leur permettre d'utiliser des sous-réseaux et des ressources dans le réseau VPC partagé. Cette association est essentielle pour que les clusters à équipe unique puissent accéder au métastore Hive centralisé.

  Comme illustré dans le schéma Mise en réseau, nous vous recommandons de créer des projets de service distincts pour le cluster de métastore Hive, les clusters multi-équipes et les clusters à équipe unique. Les membres de chaque équipe de votre organisation peuvent ensuite créer des clusters à équipe unique dans leurs projets respectifs.

Pour permettre aux composants du réseau hybride de communiquer, vous devez configurer des règles de pare-feu afin d'autoriser le trafic suivant :

• Le trafic interne de cluster pour les services Hadoop, y compris la communication de HDFS NameNameNode avec les instances de HDFS DataNode, et la communication de YARN ResourceManager avec les instances de YARN NodeManager. Nous vous recommandons d'utiliser le filtrage sur le compte de service de cluster pour ces règles.
• Le trafic externe du cluster sur des ports spécifiques, afin de communiquer avec le métastore Hive (port tcp:9083,8020), le KDC sur site (port tcp:88), le LDAP (port 636) et d'autres services externes centralisés correspondant à votre cas d'utilisation spécifique, par exemple Kafka sur Google Kubernetes Engine (GKE).

Tous les clusters Dataproc de cette architecture sont créés avec des adresses IP internes uniquement. Pour permettre aux nœuds du cluster d'accéder aux API et aux services Google, vous devez activer l'accès privé à Google pour les sous-réseaux du cluster. Pour autoriser les administrateurs et les utilisateurs expérimentés à accéder aux instances de VM sur des adresses IP privées, utilisez le transfert TCP d'IAP afin de transférer le trafic SSH et RDP ainsi que tout autre trafic via un tunnel chiffré.

Les interfaces Web des applications de cluster et les composants facultatifs (Spark, Hadoop, Jupyter et Zeppelin) sont accessibles de manière sécurisée via la passerelle des composants Dataproc. La passerelle des composants Dataproc est un proxy inverse HTTP basé sur Apache Knox.

Sur site

Ce document part du principe que les ressources sur site sont le service d'annuaire LDAP de l'entreprise et le centre de distribution de clés (KDC) Kerberos d'entreprise dans lequel les comptes principaux d'utilisateur et de service sont définis. Si vous n'avez pas besoin d'utiliser un fournisseur d'identité sur site, vous pouvez simplifier la configuration en utilisant Cloud Identity et un KDC sur cluster Dataproc ou sur machine virtuelle.

Pour communiquer avec le LDAP et le KDC sur site, vous pouvez utiliser Cloud Interconnect ou Cloud VPN. Avec cette configuration, la communication entre les environnements utilise des adresses IP privées tant que les sous-réseaux de l'adresse IP RFC 1918 ne se chevauchent pas. Pour en savoir plus sur les différentes options de connexion, consultez la page Choisir un produit de connectivité réseau.

Dans un scénario hybride, vos requêtes d'authentification doivent être traitées avec une latence minimale. Pour atteindre cet objectif, vous pouvez utiliser les techniques suivantes :

• Diffuser toutes les demandes d'authentification pour les identités de service à partir du KDC sur cluster et n'utiliser un fournisseur d'identité externe au cluster que pour les identités d'utilisateur. Bien souvent, la majeure partie du trafic d'authentification provient des requêtes créées par des identités de service.
• Si vous utilisez AD en tant que fournisseur d'identité, les noms d'utilisateurs principaux (UPN) représentent les utilisateurs humains et les comptes de service AD. Nous vous recommandons de répliquer les UPN de votre AD sur site dans une région Google Cloud proche de vos clusters de lac de données. Cette instance dupliquée AD pourra gérer les requêtes d'authentification d'UPN sans que les requêtes n'aient à transiter par votre AD sur site. Chaque KDC sur cluster gère les noms de service principaux (SPN) à l'aide de la première technique.

Le diagramme suivant illustre une architecture utilisant les deux techniques :

Dans le schéma précédent, un AD sur site synchronise les UPN avec une instance dupliquée AD dans une région Google Cloud. L'instance dupliquée AD authentifie les UPN tandis qu'un KDC sur cluster authentifie les SPN.

Pour en savoir plus sur le déploiement d'AD sur Google Cloud, consultez la page Déployer un environnement Microsoft Active Directory tolérant aux pannes. Pour savoir comment déterminer le nombre optimal d'instances pour les contrôleurs de domaine, consultez la page Intégrer MIT Kerberos et Active Directory.

Authentification

Le schéma suivant montre les composants utilisés pour authentifier les utilisateurs dans les différents clusters Hadoop. L'authentification permet aux utilisateurs d'utiliser des services tels qu'Apache Hive ou Apache Spark.

Dans le schéma précédent, les clusters des domaines Kerberos peuvent configurer l'approbation de domaine croisé pour utiliser des services sur d'autres clusters, par exemple le métastore Hive. Les clusters non-kerberisés peuvent utiliser un client Kerberos et un fichier keytab de compte afin d'utiliser des services sur d'autres clusters.

Métastore Hive partagé et sécurisé

Le métastore Hive centralisé permet à plusieurs clusters exécutant différents moteurs de requête Open Source (Apache Spark, Apache Hive/Beeline et Presto) de partager des métadonnées.

Vous devez déployer le serveur de métastore Hive sur un cluster Dataproc kerberisé avant de déployer la base de données métastore Hive sur un SGBDR distant (une instance MySQL sur Cloud SQL, par exemple). En tant que service partagé, un cluster de métastore Hive ne diffuse que des requêtes authentifiées. Pour en savoir plus sur la configuration du métastore Hive, consultez la page Utiliser Apache Hive sur Dataproc.

Au lieu du métastore Hive, vous pouvez utiliser Dataproc Metastore, un métastore Apache Hive entièrement géré, hautement disponible (dans une région) et sans serveur. Vous pouvez également activer Kerberos pour le service Dataproc Metastore, comme expliqué dans la section Configurer Kerberos pour un service.

Kerberos

Dans cette architecture, les clusters multi-équipes sont utilisés à des fins d'analyse et sont Kerberisés en suivant le guide de configuration de la sécurité Dataproc. Le mode sécurisé de Dataproc crée un KDC sur cluster et gère les comptes principaux de service et les fichiers keytab, conformément aux prérequis de la spécification du mode sécurisé de Hadoop.

Un fichier de keytab est un fichier qui contient une ou plusieurs paires de comptes principaux Kerberos ainsi qu'une copie chiffrée de la clé des comptes principaux en question. Le fichier keytab permet de gérer l'authentification Kerberos de façon programmatique lorsque la connexion interactive à l'aide de la commande kinit n'est pas possible.

L'accès à un fichier keytab implique la possibilité d'emprunter l'identité des comptes principaux contenus dans le fichier. Par conséquent, un fichier keytab est un fichier très sensible qui doit être transféré et stocké de manière sécurisée. Nous vous recommandons d'utiliser Secret Manager pour stocker le contenu des fichiers keytab avant de les transférer vers leurs clusters respectifs. Pour obtenir un exemple de stockage du contenu d'un fichier keytab, consultez la section Configurer Kerberos pour un service. Après avoir téléchargé un fichier keytab dans le nœud maître du cluster, les autorisations d'accès au fichier doivent être limitées.

Le KDC sur cluster gère les requêtes d'authentification pour tous les services du cluster. La plupart des requêtes d'authentification sont susceptibles de correspondre à ce type de requête. Pour minimiser la latence, il est important que le KDC traite ces requêtes sans qu'elles n'aient à quitter le cluster.

Les requêtes restantes proviennent d'utilisateurs humains et de comptes de service AD. Ces requêtes sont gérées par l'instance dupliquée AD sur Google Cloud ou par le fournisseur d'ID centralisé sur site, comme expliqué dans la section Sur site.

Dans cette architecture, les clusters à équipe unique ne sont pas kerberisés et ne nécessitent donc pas de KDC. Pour permettre à ces clusters d'accéder au métastore Hive partagé, il vous suffit d'installer un client Kerberos. Pour automatiser l'accès, vous pouvez utiliser le fichier keytab de l'équipe. Pour en savoir plus, consultez la section Mappage d'identité plus loin dans le présent document.

Approbation de domaine croisé Kerberos dans des clusters multi-équipes

L'approbation de domaine croisé est particulièrement pertinente lorsque vos charges de travail sont hybrides ou multicloud. L'approbation de domaine croisé vous permet d'intégrer des identités centrales d'entreprise dans les services partagés disponibles dans votre lac de données Google Cloud.

Dans Kerberos, un domaine définit un groupe de systèmes régis par un KDC commun. L'authentification de domaine croisé permet à un compte utilisateur principal d'un domaine de s'authentifier dans un autre domaine pour en utiliser les services. Cette configuration nécessite de créer une approbation de domaine croisé.

La présente architecture comprend trois domaines :

• EXAMPLE.COM : est le domaine de l'entreprise, où sont définis tous les comptes principaux d'utilisateur Kerberos pour les utilisateurs, les équipes et les services (UPN).
• MULTI.EXAMPLE.COM : est le domaine qui contient les clusters multi-équipes. Le cluster est préconfiguré avec des comptes principaux de service (SPN) pour les services Hadoop tels qu'Apache Spark et Apache Hive.
• METASTORE.EXAMPLE.COM : est un domaine pour le métastore Hive.

Les clusters à équipe unique ne sont pas kerberisés et n'appartiennent donc pas à un domaine.

Pour pouvoir utiliser les comptes principaux d'utilisateur d'entreprise sur tous les clusters, vous devez créer les approbations de domaine croisé unidirectionnelles suivantes :

• Configurez le domaine multi-équipes et le domaine de métastore pour qu'ils fassent confiance au domaine d'entreprise. Avec cette configuration, les comptes principaux définis dans le domaine d'entreprise peuvent accéder aux clusters multi-équipes ainsi qu'au métastore.

  Bien que la confiance puisse être transitive, nous vous recommandons de configurer une approbation directe du domaine d'entreprise dans le domaine de métastore. Cette configuration évite de reposer sur la disponibilité du domaine multi-équipes.

• Configurez le domaine du métastore pour qu'il fasse confiance au domaine multi-équipes, ce qui permet aux clusters multi-équipes d'accéder au métastore. Cette configuration est nécessaire pour autoriser l'accès principal à HiveServer2 pour le métastore.

Pour en savoir plus, consultez la page Premiers pas avec les clusters Dataproc kerberisés avec approbation de domaine croisé et les fichiers de configuration Terraform correspondants dans le dépôt GitHub.

Si vous préférez une approche intégrée ou cloud native avec IAM pour les clusters multi-équipes et que vous n'avez pas besoin de gestion d'identité hybride, envisagez d'utiliser l'architecture mutualisée et sécurisée basée sur un compte de service Dataproc. Dans ces clusters, plusieurs identités IAM peuvent accéder à Cloud Storage ainsi qu'à d'autres ressources Google en utilisant l'identité de différents comptes de service.

Mappage d'identité dans les clusters à équipe unique

Les sections précédentes décrivent la configuration du côté kerberisé de l'architecture. Toutefois, les clusters à équipe unique ne sont pas kerberisés. Par conséquent, une technique spéciale doit être mise en œuvre pour leur permettre de participer à cet écosystème. Cette technique utilise la propriété de séparation des projets Google Cloud et les comptes de service IAM pour isoler et sécuriser les charges de travail Hadoop des équipes d'applications.

Comme décrit dans la section précédente sur la mise en réseau, chaque équipe dispose d'un projet Google Cloud correspondant dans lequel elle peut créer des clusters à équipe unique. Au sein des clusters à équipe unique, un ou plusieurs membres de l'équipe sont les locataires du cluster. Cette méthode de séparation des projets restreint également l'accès aux buckets Cloud Storage (utilisés par ces clusters) aux équipes correspondantes.

Un administrateur crée le projet de service et provisionne le compte de service de l'équipe dans ce projet. Lors de la création d'un cluster, ce compte de service est spécifié en tant que compte de service de cluster.

L'administrateur crée également un compte principal Kerberos pour l'équipe dans le domaine d'entreprise ainsi qu'un fichier keytab correspondant. Le fichier keytab est stocké en toute sécurité dans Secret Manager et l'administrateur copie le fichier keytab dans le nœud maître du cluster. Le compte principal Kerberos permet au cluster à équipe unique d'accéder au métastore Hive.

Pour faciliter le provisionnement automatique et reconnaître facilement ces paires d'identités associées, les identités doivent suivre une convention d'attribution de noms commune, par exemple :

• Compte de service de l'équipe : [email protected]
• Compte principal de l'équipe Kerberos : revenue_reporting/[email protected]

Cette technique de mappage d'identité offre une approche unique pour mapper une identité Kerberos à un compte de service lorsqu'ils appartiennent à la même équipe.

Ces identités sont utilisées de différentes manières :

• L'identité Kerberos permet au cluster d'accéder aux ressources Hadoop partagées telles que le métastore Hive.
• Le compte de service permet au cluster d'accéder aux ressources partagées de Google Cloud telles que Cloud Storage.

Cette technique évite de créer un mappage similaire pour chaque membre de l'équipe. Cependant, comme cette technique utilise un compte de service ou un compte principal Kerberos pour l'ensemble de l'équipe, les actions du cluster Hadoop ne peuvent pas être attribuées aux membres individuels de l'équipe.

Pour gérer l'accès aux ressources cloud du projet de l'équipe qui ne relèvent pas des clusters Hadoop (tels que les buckets Cloud Storage, les services gérés et les VM), un administrateur doit ajouter les membres de l'équipe à un Groupe Google. L'administrateur peut utiliser le groupe Google pour gérer les autorisations IAM afin que toute l'équipe puisse accéder aux ressources cloud.

Lorsque vous accordez des autorisations IAM à un groupe et non à des membres individuels de l'équipe, vous simplifiez la gestion des accès utilisateur lorsque des membres rejoignent ou quittent l'équipe d'application. En accordant des autorisations IAM directes au groupe Google de l'équipe, vous pouvez désactiver l'emprunt d'identité de compte de service afin de simplifier la traçabilité des actions dans les journaux d'audit Cloud. Lorsque vous définissez les membres de votre équipe, nous vous recommandons d'équilibrer le niveau de précision requis pour la gestion des accès, l'utilisation des ressources et les audits en fonction des efforts administratifs qu'impliquent chacune de ces tâches.

Si un cluster sert exclusivement à un même utilisateur humain (cluster à locataire unique) plutôt qu'à une équipe, envisagez d'utiliser l'authentification de cluster personnel Dataproc. Les clusters sur lesquels l'authentification de cluster personnel est activée sont exclusivement utilisés pour exécuter des charges de travail interactives à court terme, de façon sécurisée et sous une seule identité d'utilisateur final. Ces clusters utilisent les identifiants de l'utilisateur final IAM pour interagir avec les autres ressources Google Cloud telles que Cloud Storage. Le cluster s'authentifie en tant qu'utilisateur final plutôt que de s'authentifier en tant que compte de service de cluster. Dans ce type de cluster, Kerberos est automatiquement activé et configuré pour une communication sécurisée au sein du cluster personnel.

Flux d'authentification

Pour exécuter une tâche sur un cluster Dataproc, les utilisateurs disposent de nombreuses options qui sont présentées en détail dans la section précédente Envoyer des tâches. Dans tous les cas, leur compte utilisateur ou compte de service doit avoir accès au cluster.

Lorsqu'un utilisateur exécute une tâche sur un cluster multi-équipes, deux choix de compte principal Kerberos sont possibles, comme indiqué dans le schéma suivant :

Le schéma précédent illustre les options suivantes :

1. Si l'utilisateur utilise un outil Google Cloud tel que l'API Dataproc, Cloud Composer ou l'outil de ligne de commande gcloud pour envoyer la requête de tâche, le cluster utilise le compte principal Kerberos de Dataproc pour s'authentifier auprès du KDC et accéder au métastore Hive.
2. Si l'utilisateur exécute une tâche à partir d'une session SSH, il peut soumettre des tâches directement dans cette session en utilisant son propre compte principal Kerberos.

Lorsqu'un utilisateur exécute une tâche sur un cluster à équipe unique, il n'existe qu'un seul compte principal Kerberos possible (le compte principal Kerberos d'équipe), comme indiqué dans le schéma suivant :

Dans le schéma précédent, une tâche utilise le compte principal Kerberos d'équipe lorsque la tâche doit accéder au métastore Hive partagé. Sinon, comme les clusters à équipe unique ne sont pas kerberisés, les utilisateurs peuvent démarrer des tâches à l'aide de leur propre compte utilisateur.

Pour les clusters à équipe unique, il est recommandé d'exécuter kinit pour le compte principal d'équipe dans le cadre d'une action d'initialisation au moment de la création du cluster. Après la création du cluster, utilisez une planification cron en fonction de la durée de vie de ticket définie et en incluant l'option de commande "lifetime" (-l). Pour exécuter kinit, l'action d'initialisation commence par télécharger le fichier keytab dans le nœud maître du cluster.

Pour des raisons de sécurité, vous devez impérativement restreindre l'accès au fichier keytab. N'accordez les autorisations de lecture POSIX qu'au compte qui exécute kinit. Si possible, supprimez le fichier keytab et renouvelez le jeton en utilisant kinit -R pour prolonger sa durée de vie avec une tâche cron jusqu'à ce qu'il ait atteint la durée de vie maximale de ticket. À ce stade, la tâche cron peut télécharger à nouveau le fichier keytab, réexécuter kinit et redémarrer le cycle de renouvellement.

Les types de clusters multi-équipes et à équipe unique utilisent des comptes de service pour accéder à d'autres ressources Google Cloud telles que Cloud Storage. Les clusters à équipe unique utilisent le compte de service de l'équipe comme compte de service du cluster personnalisé.

Autorisation

Cette section décrit les mécanismes d'autorisation généraux et spécifiques de chaque cluster, comme illustré dans le schéma suivant :

L'architecture du schéma précédent utilise IAM pour les autorisations générales et Apache Ranger pour les autorisations plus précises. Ces méthodes d'autorisation sont décrites dans les sections suivantes : Autorisations générales et Autorisations précises.

Autorisations générales

IAM vous permet de contrôler l'accès des utilisateurs et des groupes aux ressources de votre projet. IAM définit les autorisations, ainsi que les rôles qui accordent ces autorisations.

Il existe quatre rôles Dataproc prédéfinis : administrateur, éditeur, lecteur et nœud de calcul. Ces rôles accordent des autorisations Dataproc qui permettent aux utilisateurs et aux comptes de service d'effectuer des actions spécifiques sur les clusters, les tâches, les opérations et les modèles de workflow. Les rôles accordent l'accès aux ressources Google Cloud dont ils ont besoin pour accomplir leurs tâches. Cloud Storage est l'une de ces ressources. Nous vous recommandons de l'utiliser en tant que couche de stockage du cluster plutôt que d'utiliser HDFS.

La précision des autorisations IAM Dataproc ne s'étend pas au niveau des services exécutés sur chaque cluster comme Apache Hive ou Apache Spark. Par exemple, vous pouvez autoriser un compte à accéder aux données d'un bucket Cloud Storage ou à exécuter des tâches. Toutefois, vous ne pouvez pas spécifier les colonnes Hive auxquelles ce compte est autorisé à accéder avec cette tâche. La section suivante décrit comment mettre en œuvre ce type d'autorisation plus précis dans vos clusters.

Autorisations précises

Pour accorder un accès très précis, utilisez le composant facultatif Dataproc Ranger dans l'architecture décrite sur la page Bonnes pratiques pour utiliser Apache Ranger sur Dataproc. Dans cette architecture, Apache Ranger est installé sur chacun de vos clusters, qu'ils soient multi-équipes ou à équipe unique. Apache Ranger fournit un contrôle d'accès précis pour vos applications Hadoop (autorisations et audits) à l'échelle du service, de la table ou de la colonne.

Apache Ranger utilise les identités fournies par le dépôt LDAP d'entreprise, qui sont également définies en tant que comptes principaux Kerberos. Dans les clusters multi-équipes, le daemon Ranger UserSync met régulièrement à jour les identités kerberisées à partir du serveur LDAP d'entreprise. Dans les clusters à équipe unique, seule l'identité de l'équipe est requise.

Les clusters éphémères présentent un défi, car ils s'arrêtent une fois les tâches terminées mais doivent conserver leurs stratégies Ranger et leurs journaux d'administration. Pour relever ce défi, vous devez externaliser les stratégies dans une base de données Cloud SQL centrale, puis externaliser les journaux d'audit dans des dossiers Cloud Storage. Pour plus d'informations, consultez la section Bonnes pratiques pour l'utilisation d'Apache Ranger sur Dataproc.

Flux d'autorisation

Lorsqu'un utilisateur souhaite accéder à un ou plusieurs des services du cluster pour traiter des données, la requête passe par le flux suivant :

1. L'utilisateur s'authentifie via l'une des options décrites dans la section Flux d'authentification.
2. Le service cible reçoit la requête utilisateur et appelle le plug-in Apache Ranger correspondant.
3. Le plug-in récupère régulièrement les règles à partir du serveur de règles Ranger. Ces stratégies déterminent si l'identité de l'utilisateur est autorisée à effectuer l'action demandée sur le service spécifique. Si l'identité de l'utilisateur est autorisée à effectuer l'action, le plug-in permet au service de traiter la requête et l'utilisateur obtient les résultats.
4. Chaque interaction utilisateur avec un service Hadoop, qu'elle soit autorisée ou refusée, est écrite dans les journaux Ranger par le serveur d'audit Ranger. Chaque cluster possède son propre dossier de journaux dans Cloud Storage. Dataproc écrit également des journaux de tâche et de cluster que vous pouvez afficher, rechercher, filtrer et archiver dans Cloud Logging.

Dans le présent document, les architectures de référence utilisent deux types de clusters Dataproc : les clusters multi-équipes et les clusters à équipe unique. En utilisant plusieurs clusters Dataproc faciles à provisionner et à sécuriser, une entreprise peut utiliser une approche axée sur les tâches, les produits ou les domaines plutôt que des clusters traditionnels et centralisés. Cette approche fonctionne bien avec une architecture globale de maillage de données qui permet aux équipes de posséder et de sécuriser complètement leurs lacs de données et leurs charges de travail, puis de diffuser les données par l'intermédiaire d'un service.

Étape suivante

• Découvrez comment commencer à utiliser les clusters Dataproc kerberisés avec l'approbation de domaine croisé et consultez les fichiers de configuration Terraform correspondants dans le dépôt GitHub.
• Découvrez les bonnes pratiques concernant l'utilisation d'Apache Ranger sur Dataproc.
• Découvrez comment configurer un accès sécurisé aux données sur Dataproc pour les analystes de données en utilisant des outils d'informatique décisionnelle tels que Tableau et Looker.
• Découvrez comment transférer votre système Apache Hadoop sur site vers Google Cloud.
• Consultez la page Bonnes pratiques pour fédérer Google Cloud avec un fournisseur d'identité externe.
• Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.