Rôle de service pour les instances EC2 de cluster (profil d'instance EC2) - Amazon EMR

Rôle de service pour les instances EC2 de cluster (profil d'instance EC2)

Le rôle de service pour les instances EC2 de cluster (également appelé profil d'instance EC2 pour Amazon EMR) est un type spécial de rôle de service qui est attribué à chaque instance EC2 dans un cluster Amazon EMR 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 instances EC2, consultez Utilisation d'un rôle IAM pour accorder des autorisations à des applications s'exécutant sur des instances Amazon EC2 dans le Guide de l'utilisateur IAM.

Important

Le rôle de service par défaut pour les instances EC2 en cluster et sa politique gérée par AWS par défaut associée, AmazonElasticMapReduceforEC2Role, sont sur le point d'être dépréciés, aucune politique gérée par AWS 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_DefaultRole par défaut, AmazonElasticMapReduceforEC2Role, arrive en fin de support. Au lieu d'utiliser une politique gérée par défaut pour le profil d'instance EC2, 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 rôle IAM comme profil d'instance. Pour de plus amples informations, veuillez consulter Création d'un rôle de service pour les instances EC2 de cluster avec des 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 instances EC2 de cluster avec des autorisations de moindre privilège

En tant que bonne pratique, nous vous recommandons vivement de créer un rôle de service pour les instances EC2 de cluster et une politique d'autorisations qui dispose des autorisations minimales pour les autres services AWS 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 est sur le point d'être obsolète et Amazon EMR ne fournira pas de politique par défaut gérée par AWS 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 d'autorisations requises pour différentes fonctionnalités d'Amazon EMR. 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 la région us-west-2 et l'ID de compte AWS fictif 123456789012. Remplacez-les par les bonnes informations pour votre cluster.

Pour plus d'informations sur la création et la spécification des rôles personnalisés, consultez Personnaliser les rôles IAM.

Note

Si vous créez un rôle EMR personnalisé pour EC2, suivez le flux de travail de base, qui crée automatiquement un profil d'instance du même nom. Amazon EC2 vous permet de créer des profils d'instance et des rôles avec des noms différents, mais Amazon EMR ne prend pas en charge cette configuration, et il en résulte une erreur « profil d'instance non valide » lorsque vous créez le cluster.

Lecture et écriture de données sur Amazon S3 à l'aide d'EMRFS

Lorsqu'une application exécutée sur un cluster Amazon EMR référence des données à l'aide du format s3://mydata, Amazon EMR utilise le profil d'instance EC2 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 attachées au rôle de service pour les instances EC2 de cluster. Pour de plus amples informations, veuillez consulter Configuration de rôles IAM pour les demandes EMRFS à Amazon S3.

Étant donné que les rôles IAM pour EMRFS basculeront vers les autorisations attachées au rôle de service pour les instances EC2 de cluster, nous vous recommandons, à titre de bonne pratique, d'utiliser les rôles IAM pour EMRFS et de limiter les autorisations EMRFS et Amazon S3 attachées au rôle de service pour les instances EC2 de cluster.

L'exemple de déclaration ci-dessous illustre les autorisations dont EMRFS a besoin pour effectuer des demandes à Amazon S3.

  • my-data-bucket-in-s3-for-emrfs-reads-and-writes spécifie le compartiment Amazon S3 dans lequel le cluster lit et écrit les données et tous les sous-dossiers utilisant /*. Ajoutez uniquement les compartiments et les dossiers dont votre application a besoin.

  • La déclaration de politique qui autorise les actions dynamodb n'est requise que si la vue cohérente EMRFS est activée. EmrFSMetadata spécifie le dossier par défaut pour la vue cohérente EMRFS.

{ "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 permet au cluster Amazon EMR d'archiver les fichiers journaux vers l'emplacement Amazon S3 spécifié. Dans l'exemple ci-dessous, lors de la création du cluster, s3://MyLoggingBucket/MyEMRClusterLogs a été spécifié à l'aide de l'emplacement S3 du dossier Log dans la console, à l'aide de l'option --log-uri de l'AWS CLI, ou à l'aide du paramètre LogUri de la commande RunJobFlow. 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 des outils de débogage

La déclaration de stratégie suivante autorise les actions qui sont requises si vous activez l'outil de débogage Amazon EMR. L'archivage de fichiers journaux dans Amazon S3, et les autorisations associées indiquées dans l'exemple ci-dessus, sont requis pour le débogage. Pour de plus amples informations, veuillez consulter Activation de l'outil de débogage.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sqs:GetQueueUrl", "sqs:SendMessage" ], "Resource": "arn:aws:sqs:us-west-2:123456789012:AWS-ElasticMapReduce-*" } ] }

Utilisation du catalogue de données AWS Glue

La déclaration de stratégie suivante autorise les actions qui sont nécessaires si vous utilisez le catalogue de données AWS Glue en tant que métastore pour les applications. Pour plus d'informations, consultez Utilisation du catalogue de données AWS Glue en tant que métastore pour Spark SQL, Utilisation du catalogue de données AWS Glue en tant que métastore pour Hive et Utilisation de Presto avec le catalogue de données AWS Glue dans le Guide de version Amazon 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": "*", } ] }