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.
Rôle de service pour les EC2 instances de cluster (profil d'EC2instance)
Le rôle de service pour les EC2 instances de cluster (également appelé profil d'EC2instance pour AmazonEMR) est un type spécial de rôle de service attribué à chaque EC2 instance d'un EMR cluster Amazon lors du lancement de l'instance. Les processus d'application qui s'exécutent au-dessus de l'écosystème Hadoop assument ce rôle pour les autorisations permettant d'interagir avec d'autres services AWS .
Pour plus d'informations sur les rôles de service pour les EC2 instances, consultez la section Utilisation d'un IAM rôle pour accorder des autorisations aux applications exécutées sur des EC2 instances Amazon dans le Guide de IAM l'utilisateur.
Important
Le rôle de service par défaut pour les EC2 instances de cluster et la stratégie gérée AWS par défaut associée AmazonElasticMapReduceforEC2Role sont sur le point de devenir obsolètes, aucune politique AWS gérée de remplacement n'étant fournie. Vous devrez créer et spécifier un profil d'instance pour remplacer le rôle obsolète et la politique par défaut.
Rôle et stratégie gérée par défaut
-
Le nom de rôle par défaut est
EMR_EC2_DefaultRole. -
La politique gérée par
EMR_EC2_DefaultRolepar défaut,AmazonElasticMapReduceforEC2Role, arrive en fin de support. Au lieu d'utiliser une politique gérée par défaut pour le profil d'EC2instance, appliquez des politiques basées sur les ressources aux compartiments S3 et aux autres ressources dont Amazon EMR a besoin, ou utilisez votre propre politique gérée par le client avec un IAM rôle en tant que profil d'instance. Pour de plus amples informations, veuillez consulter Création d'un rôle de service pour les EC2 instances de cluster dotées d'autorisations de moindre privilège.
Vous trouverez ci-dessous le contenu de la version 3 de AmazonElasticMapReduceforEC2Role.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Resource": "*", "Action": [ "cloudwatch:*", "dynamodb:*", "ec2:Describe*", "elasticmapreduce:Describe*", "elasticmapreduce:ListBootstrapActions", "elasticmapreduce:ListClusters", "elasticmapreduce:ListInstanceGroups", "elasticmapreduce:ListInstances", "elasticmapreduce:ListSteps", "kinesis:CreateStream", "kinesis:DeleteStream", "kinesis:DescribeStream", "kinesis:GetRecords", "kinesis:GetShardIterator", "kinesis:MergeShards", "kinesis:PutRecord", "kinesis:SplitShard", "rds:Describe*", "s3:*", "sdb:*", "sns:*", "sqs:*", "glue:CreateDatabase", "glue:UpdateDatabase", "glue:DeleteDatabase", "glue:GetDatabase", "glue:GetDatabases", "glue:CreateTable", "glue:UpdateTable", "glue:DeleteTable", "glue:GetTable", "glue:GetTables", "glue:GetTableVersions", "glue:CreatePartition", "glue:BatchCreatePartition", "glue:UpdatePartition", "glue:DeletePartition", "glue:BatchDeletePartition", "glue:GetPartition", "glue:GetPartitions", "glue:BatchGetPartition", "glue:CreateUserDefinedFunction", "glue:UpdateUserDefinedFunction", "glue:DeleteUserDefinedFunction", "glue:GetUserDefinedFunction", "glue:GetUserDefinedFunctions" ] } ] }
Votre rôle de service doit utiliser la politique d'approbation suivante.
{ "Version": "2008-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
Création d'un rôle de service pour les EC2 instances de cluster dotées d'autorisations de moindre privilège
À titre de bonne pratique, nous vous recommandons vivement de créer un rôle de service pour les EC2 instances de cluster et une politique d'autorisations qui prévoit les autorisations minimales pour les autres AWS services requis par votre application.
La stratégie gérée par défaut, AmazonElasticMapReduceforEC2Role, fournit des autorisations qui facilitent le lancement d'un cluster initial. Cependant, AmazonElasticMapReduceforEC2Role il est sur le point de devenir obsolète et Amazon ne EMR fournira pas de politique AWS gérée par défaut de remplacement pour le rôle obsolète. Pour lancer un cluster initial, vous devez fournir une politique basée sur les ressources ou sur les identifiants gérée par le client.
Les déclarations de politique suivantes fournissent des exemples des autorisations requises pour les différentes fonctionnalités d'AmazonEMR. Nous vous recommandons d'utiliser ces autorisations afin de créer une stratégie d'autorisations qui restreint l'accès uniquement aux fonctionnalités et aux ressources dont votre cluster a besoin. Tous les exemples de déclarations de politique utilisent le us-west-2 Région et identifiant de AWS compte fictif 123456789012. Remplacez-les selon les besoins de votre cluster.
Pour plus d'informations sur la création et la spécification des rôles personnalisés, consultez Personnalisez IAM les rôles avec Amazon EMR.
Note
Si vous créez un EMR rôle personnalisé pourEC2, suivez le flux de travail de base, qui crée automatiquement un profil d'instance du même nom. Amazon vous EC2 permet de créer des profils d'instance et des rôles portant des noms différents, mais Amazon EMR ne prend pas en charge cette configuration, ce qui entraîne une erreur « profil d'instance non valide » lorsque vous créez le cluster.
Lire et écrire des données sur Amazon S3 à l'aide de EMRFS
Lorsqu'une application exécutée sur un EMR cluster Amazon référence des données à l'aide du s3:// format, Amazon EMR utilise le profil d'EC2instance pour effectuer la demande. Les clusters lisent et écrivent généralement des données sur Amazon S3 de cette manière, et Amazon EMR utilise par défaut les autorisations associées au rôle de service pour les EC2 instances de cluster. Pour de plus amples informations, veuillez consulter Configuration IAM des rôles pour les EMRFS demandes adressées à Amazon S3.mydata
Étant donné que les IAM rôles pour EMRFS se basent sur les autorisations associées au rôle de service pour les EC2 instances de cluster, nous vous recommandons, en tant que bonne pratiqueEMRFS, d'utiliser IAM des rôles et de limiter les EMRFS autorisations Amazon S3 associées au rôle de service pour les EC2 instances de cluster.
L'exemple de déclaration ci-dessous illustre les autorisations EMRFS requises pour envoyer des demandes à Amazon S3.
-
my-data-bucket-in-s3-for-emrfs-reads-and-writesspécifie le compartiment dans Amazon S3 dans lequel le cluster lit et écrit les données, ainsi que tous les sous-dossiers en utilisant/*. Ajoutez uniquement les compartiments et dossiers dont votre application a besoin. -
La déclaration de politique autorisant
dynamodbles actions n'est requise que si la vue EMRFS cohérente est activée.EmrFSMetadataindique le dossier par défaut pour un affichage EMRFS cohérent.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:AbortMultipartUpload", "s3:CreateBucket", "s3:DeleteObject", "s3:GetBucketVersioning", "s3:GetObject", "s3:GetObjectTagging", "s3:GetObjectVersion", "s3:ListBucket", "s3:ListBucketMultipartUploads", "s3:ListBucketVersions", "s3:ListMultipartUploadParts", "s3:PutBucketVersioning", "s3:PutObject", "s3:PutObjectTagging" ], "Resource": [ "arn:aws:s3:::my-data-bucket-in-s3-for-emrfs-reads-and-writes", "arn:aws:s3:::my-data-bucket-in-s3-for-emrfs-reads-and-writes/*" ] }, { "Effect": "Allow", "Action": [ "dynamodb:CreateTable", "dynamodb:BatchGetItem", "dynamodb:BatchWriteItem", "dynamodb:PutItem", "dynamodb:DescribeTable", "dynamodb:DeleteItem", "dynamodb:GetItem", "dynamodb:Scan", "dynamodb:Query", "dynamodb:UpdateItem", "dynamodb:DeleteTable", "dynamodb:UpdateTable" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/EmrFSMetadata" }, { "Effect": "Allow", "Action": [ "cloudwatch:PutMetricData", "dynamodb:ListTables", "s3:ListBucket" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "sqs:GetQueueUrl", "sqs:ReceiveMessage", "sqs:DeleteQueue", "sqs:SendMessage", "sqs:CreateQueue" ], "Resource": "arn:aws:sqs:us-west-2:123456789012:EMRFS-Inconsistency-*" } ] }
Archivage des fichiers journaux sur Amazon S3
La déclaration de politique suivante autorise le EMR cluster Amazon à archiver les fichiers journaux à l'emplacement Amazon S3 spécifié. Dans l'exemple ci-dessous, lorsque le cluster a été créé, s3://MyLoggingBucket/MyEMRClusterLogs a été spécifié à l'aide de l'emplacement S3 du dossier Log dans la console, à l'aide de l'--log-uri AWS CLI option du ou à l'aide du LogUri paramètre de la RunJobFlow commande. Pour de plus amples informations, veuillez consulter Archiver les fichiers journaux sur Amazon S3.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::MyLoggingBucket/MyEMRClusterLogs/*" } ] }
Utilisation du catalogue AWS de données Glue
La déclaration de politique suivante autorise les actions requises si vous utilisez le AWS Glue Data Catalog comme métastore pour les applications. Pour plus d'informations, consultez les sections Utilisation du catalogue de données AWS Glue comme métastore pour Spark SQL, Utilisation du catalogue de données AWS Glue comme métastore pour Hive et Utilisation de Presto avec le catalogue de AWS données Glue dans le Amazon Release Guide. EMR
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "glue:CreateDatabase", "glue:UpdateDatabase", "glue:DeleteDatabase", "glue:GetDatabase", "glue:GetDatabases", "glue:CreateTable", "glue:UpdateTable", "glue:DeleteTable", "glue:GetTable", "glue:GetTables", "glue:GetTableVersions", "glue:CreatePartition", "glue:BatchCreatePartition", "glue:UpdatePartition", "glue:DeletePartition", "glue:BatchDeletePartition", "glue:GetPartition", "glue:GetPartitions", "glue:BatchGetPartition", "glue:CreateUserDefinedFunction", "glue:UpdateUserDefinedFunction", "glue:DeleteUserDefinedFunction", "glue:GetUserDefinedFunction", "glue:GetUserDefinedFunctions" ], "Resource": "*", } ] }
