Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Plug-ins Apache Ranger pour les scénarios d'intégration d'Amazon EMR Les plug-ins Apache Ranger valident l'accès d'un utilisateur par rapport aux politiques d'autorisation définies sur le serveur d'administration des politiques Apache Ranger. **Topics** + [ # Plug-in Apache Hive pour l'intégration de Ranger à Amazon EMR ](emr-ranger-hive.md) + [ # Plug-in Apache Spark pour l'intégration de Ranger à Amazon EMR ](emr-ranger-spark.md) + [ # Plug-in EMRFS S3 pour l'intégration de Ranger à Amazon EMR ](emr-ranger-emrfs.md) + [ # Plug-in Trino pour l'intégration de Ranger à Amazon EMR ](emr-ranger-trino.md) # Plug-in Apache Hive pour l'intégration de Ranger à Amazon EMR Apache Hive est un moteur d'exécution populaire au sein de l'écosystème Hadoop. Amazon EMR fournit un plug-in Apache Ranger permettant de fournir des contrôles d'accès précis pour Hive. Le plug-in est compatible avec le serveur d'administration open source Apache Ranger version 2.0 et ultérieure. **Topics** + [ ## Fonctionnalités prises en charge ](#emr-ranger-supported-features) + [ ## Installation de la configuration du service ](#emr-ranger-hive-service-config) + [ ## Considérations ](#emr-ranger-hive-considerations) + [ ## Limitations ](#emr-ranger-hive-limitations) ## Fonctionnalités prises en charge Le plug-in Apache Ranger pour Hive on EMR prend en charge toutes les fonctionnalités du plug-in open source, notamment les contrôles d'accès aux bases de données, aux tables et aux colonnes, le filtrage des lignes et le masquage des données. Pour un tableau des commandes Hive et des autorisations Ranger associées, consultez [Mappage descommandes Hive aux autorisations Ranger](https://cwiki.apache.org/confluence/display/RANGER/Hive+Commands+to+Ranger+Permission+Mapping). ## Installation de la configuration du service Le plug-in Apache Hive est compatible avec la définition de service Hive existante dans Apache Hive Hadoop SQL. ![\[Définition du service Apache Hive pour Hadoop SQL.\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ManagementGuide/images/ranger_service_mgr.png) Si vous ne possédez pas d'instance du service sous Hadoop SQL, comme indiqué ci-dessus, vous pouvez en créer une. Cliquez sur le signe **\$1** à côté de Hadoop SQL. 1. **Nom du service (s'il est affiché)** : entrez le nom du service. La valeur suggérée est **amazonemrhive**. Notez le nom de ce service : il est nécessaire lors de la création d'une configuration de sécurité EMR. 1. **Nom d'affichage** : entrez le nom à afficher pour le service. La valeur suggérée est **amazonemrhive**. ![\[Détails du service Apache Hive pour Hadoop SQL.\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ManagementGuide/images/ranger_create_service.png) Les propriétés de configuration d'Apache Hive sont utilisées pour établir une connexion avec votre serveur d'administration Apache Ranger avec un HiveServer 2 pour implémenter la saisie automatique lors de la création de politiques. Les propriétés ci-dessous ne doivent pas nécessairement être exactes si vous ne disposez pas d'un processus HiveServer 2 persistant et peuvent être renseignées avec n'importe quelle information. + **Nom d'**utilisateur : entrez un nom d'utilisateur pour la connexion JDBC à une instance d'une instance HiveServer 2. + **Mot de passe** : entrez le mot de passe pour le nom d'utilisateur ci-dessus. + **jdbc.driver. ClassName**: Entrez le nom de classe de la classe JDBC pour la connectivité Apache Hive. La valeur par défaut peut être utilisée. + **jdbc.url** : Entrez la chaîne de connexion JDBC à utiliser lors de la connexion à 2. HiveServer + **Nom commun du certificat** : champ CN du certificat utilisé pour se connecter au serveur d'administration à partir d'un plug-in client. Cette valeur doit correspondre au champ CN de votre certificat TLS créé pour le plug-in. ![\[Propriétés de configuration du service Apache Hive.\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ManagementGuide/images/ranger_config_props.png) Le bouton **Tester la connexion** vérifie si les valeurs ci-dessus peuvent être utilisées pour établir une connexion réussie à l'instance HiveServer 2. Une fois le service créé avec succès, le gestionnaire de services devrait ressembler à ce qui suit : ![\[Connecté à l'instance HiveServer 2\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ManagementGuide/images/ranger_config_connected.png) ## Considérations **Serveur de métadonnées Hive** Le serveur de métadonnées Hive n'est accessible que par des moteurs fiables, en particulier Hive et `emr_record_server`, pour se protéger contre tout accès non autorisé. Le serveur de métadonnées Hive est également accessible par tous les nœuds du cluster. Le port 9083 requis permet à tous les nœuds d'accéder au nœud principal. **Authentification** Par défaut, Apache Hive est configuré pour s'authentifier à l'aide de Kerberos conformément à la configuration de sécurité EMR. HiveServer2 peuvent également être configurés pour authentifier les utilisateurs à l'aide de LDAP. Consultez [Implémentation de l'authentification LDAP pour Hive sur un cluster Amazon EMR à locataires multiples](https://aws.amazon.com/blogs/big-data/implementing-ldap-authentication-for-hive-on-a-multi-tenant-amazon-emr-cluster/) pour plus d'informations. ## Limitations Les limitations actuelles du plug-in Apache Hive sur Amazon EMR 5.x sont les suivantes : + Les rôles Hive ne sont actuellement pas pris en charge. Les instructions Grant, Revoke ne sont pas prises en charge. + La CLI Hive n'est pas prise en charge. JDBC/Beeline est le seul moyen autorisé de connecter Hive. + `hive.server2.builtin.udf.blacklist`la configuration doit être renseignée avec UDFs les informations que vous jugez dangereuses. # Plug-in Apache Spark pour l'intégration de Ranger à Amazon EMR Amazon EMR a intégré l'EMR afin de fournir un contrôle d'accès précis RecordServer pour SparkSQL. L'EMR RecordServer est un processus privilégié qui s'exécute sur tous les nœuds d'un cluster compatible avec Apache Ranger. Lorsqu'un pilote ou un exécuteur Spark exécute une instruction SparkSQL, toutes les métadonnées et demandes de données passent par le. RecordServer Pour en savoir plus sur l'EMR RecordServer, consultez la [Composants Amazon EMR à utiliser avec Apache Ranger](emr-ranger-components.md) page. **Topics** + [ ## Fonctionnalités prises en charge ](#emr-ranger-spark-supported-features) + [ ## Redéployer la définition du service pour utiliser les instructions INSERT, ALTER ou DDL ](#emr-ranger-spark-redeploy-service-definition) + [ ## Installation de la définition du service ](#emr-ranger-spark-install-servicedef) + [ ## Création de politiques SparkSQL ](#emr-ranger-spark-create-sparksql) + [ ## Considérations ](#emr-ranger-spark-considerations) + [ ## Limitations ](#emr-ranger-spark-limitations) ## Fonctionnalités prises en charge | statement/Ranger Action SQL | STATUS | Version EMR pris en charge | | --- | --- | --- | | SELECT | Pris en charge | À partir de 5.32 | | SHOW DATABASES | Pris en charge | À partir de 5.32 | | SHOW COLUMNS | Pris en charge | À partir de 5.32 | | SHOW TABLES | Pris en charge | À partir de 5.32 | | SHOW TABLE PROPERTIES | Pris en charge | À partir de 5.32 | | DESCRIBE TABLE | Pris en charge | À partir de 5.32 | | INSERT OVERWRITE | Pris en charge | À partir de 5.34 et 6.4 | | INSERT INTO | Pris en charge | À partir de 5.34 et 6.4 | | ALTER TABLE | Pris en charge | À partir de 6.4 | | CREATE TABLE | Pris en charge | Àpartir de 5.35 et 6.7 | | CREATE DATABASE | Pris en charge | Àpartir de 5.35 et 6.7 | | DROP TABLE | Pris en charge | Àpartir de 5.35 et 6.7 | | DROP DATABASE | Pris en charge | Àpartir de 5.35 et 6.7 | | DROP VIEW | Pris en charge | Àpartir de 5.35 et 6.7 | | CREATE VIEW | Non pris en charge | | Les fonctionnalités suivantes sont prises en charge lors de l'utilisation de SparkSQL : + Un contrôle d'accès précis sur les tables du métastore Hive et des politiques peuvent être créées au niveau de la base de données, de la table et de la colonne. + Les politiques Apache Ranger peuvent inclure des politiques d'octroi et de refus pour les utilisateurs et les groupes. + Les événements d'audit sont soumis à CloudWatch Logs. ## Redéployer la définition du service pour utiliser les instructions INSERT, ALTER ou DDL **Note** À partir d'Amazon EMR 6.4, vous pouvez utiliser Spark SQL avec les instructions : INSERT INTO, INSERT OVERWRITE ou ALTER TABLE. À partir d'Amazon EMR 6.7, vous pouvez utiliser Spark SQL pour créer ou supprimer des bases de données et des tables. Si vous disposez d'une installation existante sur le serveur Apache Ranger avec des définitions de service Apache Spark déployées, utilisez le code suivant pour redéployer les définitions de service. ``` # Get existing Spark service definition id calling Ranger REST API and JSON processor curl --silent -f -u : \ -H "Accept: application/json" \ -H "Content-Type: application/json" \ -k 'https://**:6182/service/public/v2/api/servicedef/name/amazon-emr-spark' | jq .id # Download the latest Service definition wget https://s3.amazonaws.com/elasticmapreduce/ranger/service-definitions/version-2.0/ranger-servicedef-amazon-emr-spark.json # Update the service definition using the Ranger REST API curl -u : -X PUT -d @ranger-servicedef-amazon-emr-spark.json \ -H "Accept: application/json" \ -H "Content-Type: application/json" \ -k 'https://**:6182/service/public/v2/api/servicedef/' ``` ## Installation de la définition du service L'installation de la définition du service Apache Spark d'EMR nécessite la configuration du serveur d'administration Ranger. Consultez [Configurer un serveur d'administration Ranger pour l'intégrer à Amazon EMR](emr-ranger-admin.md). Pour installer la définition du service Apache Spark, procédez comme suit : **Étape 1 : connexion SSH au serveur d'administration Apache Ranger** Par exemple : ``` ssh ec2-user@ip-xxx-xxx-xxx-xxx.ec2.internal ``` **Étape 2 : téléchargez la définition du service et le plug-in du serveur d'administration Apache Ranger** Dans un répertoire temporaire, téléchargez la définition de service. Cette définition de service est prise en charge par les versions 2.x de Ranger. ``` mkdir /tmp/emr-spark-plugin/ cd /tmp/emr-spark-plugin/ wget https://s3.amazonaws.com/elasticmapreduce/ranger/service-definitions/version-2.0/ranger-spark-plugin-2.x.jar wget https://s3.amazonaws.com/elasticmapreduce/ranger/service-definitions/version-2.0/ranger-servicedef-amazon-emr-spark.json ``` **Étape 3 : installez le plug-in Apache Spark pour Amazon EMR** ``` export RANGER_HOME=.. # Replace this Ranger Admin's home directory eg /usr/lib/ranger/ranger-2.0.0-admin mkdir $RANGER_HOME/ews/webapp/WEB-INF/classes/ranger-plugins/amazon-emr-spark mv ranger-spark-plugin-2.x.jar $RANGER_HOME/ews/webapp/WEB-INF/classes/ranger-plugins/amazon-emr-spark ``` **Étape 4 : enregistrez la définition du service Apache Spark pour Amazon EMR** ``` curl -u **:*_<_**_password_ **_for_** _ranger admin user_**_>_* -X POST -d @ranger-servicedef-amazon-emr-spark.json \ -H "Accept: application/json" \ -H "Content-Type: application/json" \ -k 'https://**:6182/service/public/v2/api/servicedef' ``` Si cette commande s'exécute correctement, un nouveau service appelé « AMAZON-EMR-SPARK » s'affiche dans votre interface utilisateur d'administration de Ranger, comme indiqué dans l'image suivante (la version 2.0 de Ranger est illustrée). ![\[« AMAZON-EMR-SPARK » est enregistré dans Ranger Admin.\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ManagementGuide/images/ranger-amazon-emr-spark.png) **Étape 5 : créer une instance de l' AMAZON-EMR-SPARKapplication** **Nom du service (s'il est affiché) :** nom du service qui sera utilisé. La valeur suggérée est **amazonemrspark**. Notez le nom de ce service car il sera nécessaire lors de la création d'une configuration de sécurité EMR. **Nom d'affichage :** nom à afficher pour cette instance. La valeur suggérée est **amazonemrspark**. **Nom commun du certificat :** champ CN du certificat utilisé pour se connecter au serveur d'administration à partir d'un plug-in client. Cette valeur doit correspondre au champ CN de votre certificat TLS créé pour le plug-in. ![\[Ranger Admin : service de création.\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ManagementGuide/images/ranger-create-service.png) **Note** Le certificat TLS pour ce plug-in doit avoir été enregistré dans le magasin de confiance sur le serveur Ranger Admin. Pour plus d’informations, consultez [Certificats TLS pour l'intégration d'Apache Ranger à Amazon EMR](emr-ranger-admin-tls.md). ## Création de politiques SparkSQL Lors de la création d'une nouvelle politique, les champs à remplir sont les suivants : **Nom de politique** : le nom de cette politique. **Étiquette de politique** : une étiquette que vous pouvez attribuer à cette politique. **Base de données** : base de données à laquelle cette politique s'applique. Le caractère générique « \$1 » représente toutes les bases de données. **Table** : les tables auxquelles cette politique s'applique. Le caractère générique "\$1" représente toutes les tables. **Colonne EMR Spark** : colonnes auxquelles s'applique cette politique. Le caractère générique "\$1" représente toutes les colonnes. **Description** : description de cette stratégie. ![\[Ranger Admin : détails de la politique de création de SparkSQL.\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ManagementGuide/images/ranger-create-policy-details.png) Pour spécifier les utilisateurs et les groupes, entrez les utilisateurs et les groupes ci-dessous pour accorder des autorisations. Vous pouvez également spécifier des exclusions pour les conditions **autoriser** et **refuser**. ![\[Ranger Admin : détails de la politique SparkSQL, conditions d'autorisation.\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ManagementGuide/images/ranger-create-policy-allow-conditions.png) Après avoir spécifié les conditions d'autorisation et de refus, cliquez sur **Enregistrer**. ## Considérations Chaque nœud du cluster EMR doit être en mesure de se connecter au nœud principal sur le port 9083. ## Limitations Les limitations actuelles du plug-in Apache Spark sont les suivantes : + Le serveur d'enregistrement se connecte toujours à HMS s'exécutant sur un cluster Amazon EMR. Configurez HMS pour qu'il se connecte au mode distant, si nécessaire. Vous ne devez pas placer de valeurs de configuration dans le fichier de configuration Hive-site.xml d'Apache Spark. + Les tableaux créés à l'aide de sources de données Spark au format CSV ou Avro ne sont pas lisibles à l'aide de l'EMR. RecordServer Utilisez Hive pour créer et écrire des données, et lisez avec Record. + Les tables Delta Lake, Hudi et Iceberg ne sont pas prises en charge. + Les utilisateurs doivent avoir accès à la base de données par défaut. C'est une exigence pour Apache Spark. + Le serveur Ranger Admin ne prend pas en charge l'auto-complétion. + Le plug-in SparkSQL pour Amazon EMR ne prend pas en charge les filtres de lignes ni le masquage des données. + Lorsque vous utilisez ALTER TABLE avec Spark SQL, l'emplacement d'une partition doit être le répertoire enfant d'un emplacement de table. L'insertion de données dans une partition dont l'emplacement est différent de celui de la table n'est pas prise en charge. # Plug-in EMRFS S3 pour l'intégration de Ranger à Amazon EMR Pour faciliter le contrôle d'accès aux objets dans S3 sur un cluster multi-tenant, le plug-in EMRFS S3 fournit des contrôles d'accès aux données de S3 lorsque vous y accédez via EMRFS. Vous pouvez autoriser l'accès aux ressources S3 au niveau des utilisateurs et des groupes. Pour ce faire, lorsque votre application tente d'accéder à des données dans S3, EMRFS envoie une demande d'informations d'identification au processus de l'agent secret, où la demande est authentifiée et autorisée par le biais d'un plug-in Apache Ranger. Si la demande est autorisée, l'agent secret assume le rôle IAM pour les moteurs Apache Ranger avec une politique restreinte pour générer des informations d'identification qui n'ont accès qu'à la politique Ranger autorisant l'accès. Les informations d'identification sont ensuite renvoyées à EMRFS pour accéder à S3. **Topics** + [ ## Fonctionnalités prises en charge ](#emr-ranger-emrfs-features) + [ ## Installation de la configuration du service ](#emr-ranger-emrfs-service-config) + [ ## Création de politiques EMRFS S3 ](#emr-ranger-emrfs-create-policies) + [ ## Notes d'utilisation des politiques EMRFS S3 ](#emr-ranger-emrfs-considerations) + [ ## Limitations ](#emr-ranger-emrfs-limitations) ## Fonctionnalités prises en charge Le plug-in EMRFS S3 fournit une autorisation au niveau de stockage. Des politiques peuvent être créées pour permettre aux utilisateurs et aux groupes d'accéder aux compartiments et aux préfixes S3. L'autorisation n'est accordée qu'à l'encontre d'EMRFS. ## Installation de la configuration du service Pour installer la définition du service EMRFS, vous devez configurer le serveur d'administration Ranger. Pour configurer le serveur, voir[Configurer un serveur d'administration Ranger pour l'intégrer à Amazon EMR](emr-ranger-admin.md). Procédez comme suit pour installer la définition du service EMRFS. **Étape 1 : connectez-vous en SSH au serveur d'administration Apache Ranger**. Par exemple : ``` ssh ec2-user@ip-xxx-xxx-xxx-xxx.ec2.internal ``` **Étape 2 : Téléchargez la définition du service EMRFS.** Dans un répertoire temporaire, téléchargez la définition du service Amazon EMR. Cette définition de service est prise en charge par les versions 2.x de Ranger. ``` wget https://s3.amazonaws.com/elasticmapreduce/ranger/service-definitions/version-2.0/ranger-servicedef-amazon-emr-emrfs.json ``` **Étape 3 : enregistrer la définition du service EMRFS S3.** ``` curl -u **:*_<_**_password_ **_for_** _ranger admin user_**_>_* -X POST -d @ranger-servicedef-amazon-emr-emrfs.json \ -H "Accept: application/json" \ -H "Content-Type: application/json" \ -k 'https://**:6182/service/public/v2/api/servicedef' ``` Si cette commande s'exécute correctement, vous verrez apparaître un nouveau service dans l'interface utilisateur d'administration de Ranger appelé « AMAZON-EMR-S3 », comme indiqué dans l'image suivante (la version 2.0 de Ranger est illustrée). ![\[Ranger Admin : créer un service EMRFS S3.\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ManagementGuide/images/ranger-create-service-EMRFS.png) **Étape 4 : créer une instance de l' AMAZON-EMR-EMRFSapplication**. Créez une instance de la définition de service. + Cliquez sur le signe **\$1** à côté de AMAZON-EMR-EMRFS. Remplissez les champs suivants : **Nom du service (s'il est affiché)** : la valeur suggérée est **amazonemrs3**. Notez le nom de ce service car il sera nécessaire lors de la création d'une configuration de sécurité EMR. **Nom d'affichage** : nom affiché pour ce service. La valeur suggérée est **amazonemrs3**. **Nom commun du certificat** : champ CN du certificat utilisé pour se connecter au serveur d'administration à partir d'un plug-in client. Cette valeur doit correspondre au champ CN du certificat TLS créé pour le plug-in. ![\[Ranger Admin : modifier le service EMRFS S3.\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ManagementGuide/images/ranger-edit-service-EMRFS.png) **Note** Le certificat TLS pour ce plug-in doit avoir été enregistré dans le magasin de confiance sur le serveur Ranger Admin. Pour plus d’informations, consultez [Certificats TLS pour l'intégration d'Apache Ranger à Amazon EMR](emr-ranger-admin-tls.md). Lorsque le service est créé, le gestionnaire de services inclut « AMAZON-EMR-EMRFS », comme indiqué dans l'image suivante. ![\[Ranger Admin affiche le nouveau service EMRFS S3.\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ManagementGuide/images/ranger-new-service-EMRFS.png) ## Création de politiques EMRFS S3 Pour créer une nouvelle politique sur la page **Créer une politique** du Service Manager, renseignez les champs suivants. **Nom de politique** : le nom de cette politique. **Étiquette de politique** : une étiquette que vous pouvez attribuer à cette politique. **Ressource S3** : ressource commençant par le compartiment et le préfixe facultatif. Consultez [Notes d'utilisation des politiques EMRFS S3](#emr-ranger-emrfs-considerations) pour obtenir des informations sur les bonnes pratiques. Les ressources du serveur d'administration Ranger ne doivent pas contenir **s3://**, **s3a://** ou **s3n://**. ![\[Ranger Admin affiche la politique de création du service EMRFS S3.\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ManagementGuide/images/ranger-create-policy-EMRFS.png) Vous pouvez spécifier les utilisateurs et les groupes auxquels accorder des autorisations. Vous pouvez également spécifier des exclusions pour les conditions **autoriser** et **refuser**. ![\[Ranger Admin affichant user/group les autorisations pour la politique EMRFS S3.\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ManagementGuide/images/ranger-permissions-EMRFS.png) **Note** Trois ressources au maximum sont autorisées pour chaque politique. L'ajout de plus de trois ressources peut entraîner une erreur lorsque cette politique est utilisée sur un cluster EMR. L'ajout de plus de trois politiques affiche un rappel concernant la limite de politique. ## Notes d'utilisation des politiques EMRFS S3 Lors de la création de politiques S3 dans Apache Ranger, il convient de prendre en compte certaines considérations d'utilisation. ### Autorisations d'accès à plusieurs objets S3 Vous pouvez utiliser des politiques récursives et des expressions génériques pour accorder des autorisations à plusieurs objets S3 dotés de préfixes communs. Les politiques récursives accordent des autorisations à tous les objets ayant un préfixe commun. Les expressions génériques sélectionnent plusieurs préfixes. Ensemble, ils donnent des autorisations à tous les objets ayant plusieurs préfixes communs, comme le montrent les exemples suivants. **Example Utilisation d'une politique récursive** Supposons que vous souhaitiez obtenir des autorisations pour répertorier tous les fichiers de parquet d'un compartiment S3 organisés comme suit. ``` s3://sales-reports/americas/ +- year=2000 | +- data-q1.parquet | +- data-q2.parquet +- year=2019 | +- data-q1.json | +- data-q2.json | +- data-q3.json | +- data-q4.json | +- year=2020 | +- data-q1.parquet | +- data-q2.parquet | +- data-q3.parquet | +- data-q4.parquet | +- annual-summary.parquet +- year=2021 ``` Tout d'abord, considérez les fichiers de parquet avec le préfixe `s3://sales-reports/americas/year=2000`. Vous pouvez leur accorder des GetObject autorisations de deux manières : **Utilisation de politiques non récursives** : l'une des options consiste à utiliser deux politiques non récursives distinctes, l'une pour le répertoire et l'autre pour les fichiers. La première politique autorise le préfixe `s3://sales-reports/americas/year=2020` (il n'y a pas de `/` à la fin). ``` - S3 resource = "sales-reports/americas/year=2000" - permission = "GetObject" - user = "analyst" ``` La deuxième politique utilise une expression générique pour accorder des autorisations à tous les fichiers avec un préfixe `sales-reports/americas/year=2020/` (notez le `/` à la fin). ``` - S3 resource = "sales-reports/americas/year=2020/*" - permission = "GetObject" - user = "analyst" ``` **Utilisation d'une politique récursive** : une alternative plus pratique consiste à utiliser une seule politique récursive et à accorder une autorisation récursive au préfixe. ``` - S3 resource = "sales-reports/americas/year=2020" - permission = "GetObject" - user = "analyst" - is recursive = "True" ``` Jusqu'à présent, seuls les fichiers de parquet avec le préfixe `s3://sales-reports/americas/year=2000` ont été inclus. Vous pouvez désormais également inclure les fichiers parquet avec un préfixe différent, `s3://sales-reports/americas/year=2020`, dans la même politique récursive en introduisant une expression générique comme suit. ``` - S3 resource = "sales-reports/americas/year=20?0" - permission = "GetObject" - user = "analyst" - is recursive = "True" ``` ### Politiques PutObject et DeleteObject autorisations La rédaction de politiques `PutObject` et d'`DeleteObject`autorisations pour les fichiers sur EMRFS nécessite une attention particulière car, contrairement aux GetObject autorisations, elles nécessitent des autorisations récursives supplémentaires accordées au préfixe. **Example Politiques PutObject et DeleteObject autorisations** Par exemple, la suppression du fichier ne `annual-summary.parquet` nécessite pas seulement une DeleteObject autorisation d'accès au fichier lui-même. ``` - S3 resource = "sales-reports/americas/year=2020/annual-summary.parquet" - permission = "DeleteObject" - user = "analyst" ``` Il nécessite également une politique accordant une récursivité `GetObject` et des autorisations `PutObject` à son préfixe. De même, la modification du fichier `annual-summary.parquet` ne nécessite pas seulement une autorisation `PutObject` pour le fichier lui-même. ``` - S3 resource = "sales-reports/americas/year=2020/annual-summary.parquet" - permission = "PutObject" - user = "analyst" ``` Il nécessite également une politique accordant une autorisation `GetObject` récursive à son préfixe. ``` - S3 resource = "sales-reports/americas/year=2020" - permission = "GetObject" - user = "analyst" - is recursive = "True" ``` ### Des caractères génériques dans les politiques Les caractères génériques peuvent être spécifiés dans deux domaines. Lorsque vous spécifiez une ressource S3, « \$1 » et « ? » peut être utilisé. « \$1 » fournit une correspondance avec un chemin S3 et correspond à tout ce qui se trouve après le préfixe. Par exemple, la politique suivante. ``` S3 resource = "sales-reports/americas/*" ``` Cela correspond aux chemins S3 suivants. ``` sales-reports/americas/year=2020/ sales-reports/americas/year=2019/ sales-reports/americas/year=2019/month=12/day=1/afile.parquet sales-reports/americas/year=2018/month=6/day=1/afile.parquet sales-reports/americas/year=2017/afile.parquet ``` Le caractère générique « ? » ne correspond qu'à un seul caractère. Par exemple, pour la politique. ``` S3 resource = "sales-reports/americas/year=201?/" ``` Cela correspond aux chemins S3 suivants. ``` sales-reports/americas/year=2019/ sales-reports/americas/year=2018/ sales-reports/americas/year=2017/ ``` ### Caractères génériques dans les utilisateurs Deux caractères génériques sont intégrés lors de l'attribution d'utilisateurs afin de leur donner accès. Le premier est le caractère générique est « \$1USER\$1 » qui donne accès à tous les utilisateurs. Le deuxième caractère générique est « \$1OWNER\$1 », qui donne accès au propriétaire d'un objet particulier ou directement. Cependant, le caractère générique « \$1USER\$1 » n'est actuellement pas pris en charge. ## Limitations Les limites actuelles du plug-in EMRFS S3 sont les suivantes : + Les politiques d'Apache Ranger peuvent comporter au maximum trois politiques. + L'accès à S3 doit être effectué via EMRFS et peut être utilisé avec des applications liées à Hadoop. Les éléments suivants ne sont pas pris en charge : - Bibliothèques Boto3 - AWS SDK et CLI AWK - Connecteur open source S3A + Les politiques de refus d'Apache Ranger ne sont pas prises en charge. + Les opérations sur S3 avec des clés chiffrées par CSE-KMS ne sont actuellement pas prises en charge. + La prise en charge interrégionale n'est pas prise en charge. + La fonction de zone de sécurité dans Apache Ranger n'est pas prise en charge. Les restrictions de contrôle d'accès définies à l'aide de la fonctionnalité Zone de sécurité ne sont pas appliquées sur vos clusters Amazon EMR. + L'utilisateur Hadoop ne génère aucun événement d'audit car Hadoop accède toujours au profil d'instance EC2. + Il est recommandé de désactiver Amazon EMR Consistency View. Le S3 est très cohérent, il n'est donc plus nécessaire. Consultez [Forte cohérence d'Amazon S3](https://aws.amazon.com/s3/consistency/) pour plus d'informations. + Le plug-in EMRFS S3 effectue de nombreux appels STS. Il est conseillé d'effectuer des tests de charge sur un compte de développement et de surveiller le volume d'appels STS. Il est également recommandé de faire une demande STS pour augmenter les limites AssumeRole de service. + Le serveur d'administration Ranger ne prend pas en charge la saisie automatique. # Plug-in Trino pour l'intégration de Ranger à Amazon EMR Trino (anciennement PrestoSQL) est un moteur de requêtes SQL que vous pouvez utiliser pour exécuter des requêtes sur des sources de données telles que HDFS, le stockage d'objets, les bases de données relationnelles et les bases de données NoSQL. Il élimine le besoin de migrer les données vers un emplacement central et vous permet d'interroger les données où qu'elles se trouvent. Amazon EMR fournit un plug-in Apache Ranger pour fournir des contrôles d'accès précis pour Trino. Le plug-in est compatible avec le serveur d'administration open source Apache Ranger version 2.0 et ultérieure. **Topics** + [ ## Fonctionnalités prises en charge ](#emr-ranger-trino-features) + [ ## Installation de la configuration du service ](#emr-ranger-trino-service-config) + [ ## Création de politiques Trino ](#emr-ranger-trino-create-policies) + [ ## Considérations ](#emr-ranger-trino-considerations) + [ ## Limitations ](#emr-ranger-trino-limitations) ## Fonctionnalités prises en charge Le plug-in Apache Ranger pour Trino sur Amazon EMR prend en charge toutes les fonctionnalités du moteur de requête Trino, qui est protégé par un contrôle d'accès précis. Cela inclut les contrôles d'accès au niveau des bases de données, des tables et des colonnes, ainsi que le filtrage des lignes et le masquage des données. Les politiques Apache Ranger peuvent inclure des politiques d'octroi et de refus pour les utilisateurs et les groupes. Les événements d'audit sont également soumis aux CloudWatch journaux. ## Installation de la configuration du service L'installation de la définition de service Trino nécessite que le serveur Ranger Admin soit configuré. Pour configurer le serveur Ranger Admin, consultez [Configurer un serveur d'administration Ranger pour l'intégrer à Amazon EMR](emr-ranger-admin.md). Procédez comme suit pour installer la définition de service Trino. 1. Connectez-vous en SSH au serveur d'administration Apache Ranger. ``` ssh ec2-user@ip-xxx-xxx-xxx-xxx.ec2.internal ``` 1. Désinstallez le plug-in du serveur Presto, s'il existe. Exécutez la commande suivante. Si le message d'erreur « Service introuvable » s'affiche, cela signifie que le plug-in du serveur Presto n'a pas été installé sur votre serveur. Passez à l'étape suivante. ``` curl -f -u **:*_<_**_password_ **_for_** _ranger admin user_**_>_* -X DELETE -k 'https://**:6182/service/public/v2/api/servicedef/name/presto' ``` 1. Téléchargez la définition du service et le plug-in du serveur d'administration Apache Ranger. Dans un répertoire temporaire, téléchargez la définition de service. Cette définition de service est prise en charge par les versions 2.x de Ranger. ``` wget https://s3.amazonaws.com/elasticmapreduce/ranger/service-definitions/version-2.0/ranger-servicedef-amazon-emr-trino.json ``` 1. Enregistrez la définition du service Apache Trino pour Amazon EMR. ``` curl -u **:*_<_**_password_ **_for_** _ranger admin user_**_>_* -X POST -d @ranger-servicedef-amazon-emr-trino.json \ -H "Accept: application/json" \ -H "Content-Type: application/json" \ -k 'https://**:6182/service/public/v2/api/servicedef' ``` Si cette commande s'exécute correctement, vous verrez un nouveau service appelé `TRINO` dans l'interface utilisateur de votre Ranger Admin, comme indiqué dans l'image suivante. ![\[Ranger Admin : service de création.\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ManagementGuide/images/ranger-create-service-trino.png) 1. Créez une instance de l'application `TRINO` en saisissant les informations suivantes. **Nom du service** : nom du service que vous allez utiliser. La valeur suggérée est `amazonemrtrino`. Notez ce nom de service, car il sera nécessaire lors de la création d'une configuration de sécurité Amazon EMR. **Nom d'affichage** : nom à afficher pour cette instance. La valeur suggérée est `amazonemrtrino`. ![\[Ranger Admin : nom d'affichage.\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ManagementGuide/images/ranger-display-name-trino.png) **jdbc.driver. ClassName**: nom de classe de la classe JDBC pour la connectivité Trino. Vous pouvez utiliser la valeur par défaut. **jdbc.url** : chaîne de connexion JDBC à utiliser lors de la connexion au coordinateur Trino. **Nom commun du certificat** : champ CN du certificat utilisé pour se connecter au serveur d'administration à partir d'un plug-in client. Cette valeur doit correspondre au champ CN de votre certificat TLS créé pour le plug-in. ![\[Ranger Admin : nom commun.\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ManagementGuide/images/ranger-common-name-trino.png) Notez que le certificat TLS de ce plug-in doit avoir été enregistré dans le trust store du serveur d'administration Ranger. Pour plus d'informations, consultez [Certificats TLS](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-ranger-admin-tls.html). ## Création de politiques Trino Lorsque vous créez une nouvelle politique, renseignez les champs suivants. **Nom de politique** : le nom de cette politique. **Étiquette de politique** : une étiquette que vous pouvez attribuer à cette politique. **Catalogue** : catalogue auquel s'applique cette politique. Le caractère générique « \$1 » représente tous les catalogues. **Schéma** : schémas auxquels s'applique cette politique. Le caractère générique « \$1 » représente tous les schémas. **Table** : les tables auxquelles cette politique s'applique. Le caractère générique "\$1" représente toutes les tables. **Colonne** : colonnes auxquelles s'applique cette politique. Le caractère générique "\$1" représente toutes les colonnes. **Description** : description de cette stratégie. D'autres types de politiques existent pour l'**Utilisateur Trino** (pour l'accès par emprunt d'identité), la **Propriété Trino System/Session** (pour modifier les propriétés du système ou de la session du moteur), les **Fonctions/procédures** (pour autoriser les appels de fonction ou de procédure) et l'**URL** (pour accorder un accès en lecture/écriture au moteur sur les emplacements de données). ![\[Ranger Admin : détails de la politique de création.\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ManagementGuide/images/ranger-create-policy-details-trino.png) Pour accorder des autorisations à des utilisateurs et à des groupes spécifiques, entrez les utilisateurs et les groupes. Vous pouvez également spécifier des exclusions pour les conditions **autoriser** et **refuser**. ![\[Ranger Admin : détails de la politique, conditions d'autorisation et de refus.\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ManagementGuide/images/ranger-create-policy-allow-conditions-trino.png) Après avoir spécifié les conditions d'autorisation et de refus, choisissez **Enregistrer**. ## Considérations Lorsque vous créez des politiques Trino dans Apache Ranger, vous devez tenir compte de certaines considérations d'utilisation. **Serveur de métadonnées Hive** Le serveur de métadonnées Hive n'est accessible que par des moteurs fiables, en particulier le moteur Trino, afin de se protéger contre tout accès non autorisé. Le serveur de métadonnées Hive est également accessible par tous les nœuds du cluster. Le port 9083 requis permet à tous les nœuds d'accéder au nœud principal. **Authentification** Par défaut, Trino est configuré pour s'authentifier à l'aide de Kerberos conformément à la configuration de sécurité Amazon EMR. **Chiffrement en transit requis** Le plug-in Trino nécessite que le chiffrement en transit soit activé dans la configuration de sécurité Amazon EMR. Pour activer le chiffrement, consultez [Chiffrement en transit](emr-data-encryption-options.md#emr-encryption-intransit). ## Limitations Les limites actuelles du plug-in Trino sont les suivantes : + Le serveur Ranger Admin ne prend pas en charge l'auto-complétion.