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.
EMRFSPlug-in S3
Pour faciliter le contrôle d'accès aux objets dans S3 sur un cluster à locataires multiples, le plugin EMRFS S3 fournit des contrôles d'accès aux données de S3 lorsque vous y accédez viaEMRFS. 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 IAM rôle d'Apache Ranger Engines 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.
Rubriques
Fonctionnalités prises en charge
EMRFSLe plugin S3 fournit une autorisation de 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 ne se fait que contreEMRFS.
Installation de la configuration du service
Pour installer la définition EMRFS de service, vous devez configurer le serveur d'administration Ranger. Pour configurer le serveur, voirConfiguration du serveur d'administration Ranger.
Procédez comme suit pour installer la définition EMRFS de service.
Étape 1 : SSH dans le 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 EMRFS service.
Dans un répertoire temporaire, téléchargez la définition du EMR service Amazon. 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 *<admin users login>*:*_<_**_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://*<RANGER SERVER ADDRESS>*: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).
Étape 4 : Créez une instance de l'EMRFSapplication AMAZON EMR - -.
Créez une instance de la définition de service.
-
Cliquez sur le signe + à côté de AMAZON - EMR -EMRFS.
Remplissez les champs suivants :
Nom du service (s'il est affiché) : la valeur suggérée est amazonemrspark. Notez ce nom de service car il sera nécessaire lors de la création d'une configuration EMR de sécurité.
Nom d'affichage : nom affiché pour ce service. 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 du TLS certificat créé pour le plugin.
Note
Le TLS certificat de ce plugin doit avoir été enregistré dans le trust store du serveur d'administration Ranger. Pour plus d’informations, consultez TLScertificats.
Lorsque le service est créé, le gestionnaire de services inclut EMRFS « AMAZON - EMR - », comme indiqué dans l'image suivante.
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 EMRFSNotes d'utilisation des politiques S3 pour obtenir des informations sur les bonnes pratiques. Les ressources du serveur d'administration Ranger ne doivent pas contenir s3://, s3a:// ou s3n://.
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.
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 EMR cluster. L'ajout de plus de trois politiques affiche un rappel concernant la limite de politique.
EMRFSNotes d'utilisation des politiques 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.
Exemple 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 accorder GetObject des autorisations à chacun d'entre eux 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'DeleteObjectautorisations pour les fichiers concernés 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.
Exemple 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, « * » et « ? » peut être utilisé. « * » 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 joker « {USER} » qui donne accès à tous les utilisateurs. Le deuxième caractère générique est « {OWNER} », qui donne accès au propriétaire d'un objet particulier ou directement. Cependant, le caractère générique « {USER} » n'est actuellement pas pris en charge.
Limites
Les limites actuelles du plugin EMRFS S3 sont les suivantes :
-
Les politiques d'Apache Ranger peuvent comporter au maximum trois politiques.
-
L'accès à S3 doit être effectué via des applications liées à Hadoop EMRFS et peut être utilisé avec celles-ci. Les éléments suivants ne sont pas pris en charge :
- Bibliothèques Boto3
- AWS SDK et AWK CLI
- 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 CSE KMS cryptées 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é de zone de sécurité ne sont pas appliquées à vos EMR clusters Amazon.
-
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
pour plus d'informations. -
Le plugin EMRFS S3 effectue de nombreux STS appels. Il est conseillé d'effectuer des tests de charge sur un compte de développement et de surveiller le volume STS d'appels. Il est également recommandé de faire une STS demande d'augmentation des limites AssumeRole de service.
-
Le serveur d'administration Ranger ne prend pas en charge la saisie automatique.
