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

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' EC2 instance pour Amazon EMR) est un type spécial de rôle de service attribué à chaque EC2 instance d'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 EC2 instances, consultez la section Utilisation d'un rôle IAM pour accorder des autorisations aux applications exécutées sur des EC2 instances Amazon dans le guide de l'utilisateur IAM.

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_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' EC2 instance, 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 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 EMR ne 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 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 us-west-2 région et l'identifiant de AWS compte fictif123456789012. 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 Personnalisez les rôles IAM avec Amazon EMR.

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 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.

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 s3://mydata format, Amazon EMR utilise le profil d' EC2 instance 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 de rôles IAM pour les demandes EMRFS à Amazon S3.

Étant donné que les rôles IAM pour EMRFS se basent sur les autorisations associées au rôle de service pour les EC2 instances de cluster, il est recommandé d'utiliser des rôles IAM pour EMRFS et de limiter les autorisations EMRFS et Amazon S3 associées au rôle de service pour les instances de cluster. EC2

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, lorsque le cluster a été créé, il 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 guide de mise à jour d'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": "*", } ] }