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 du cluster et la politique 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'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 plus d’informations, consultez 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

À titre de bonne pratique, nous vous recommandons vivement de créer un rôle de service pour les instances EC2 du 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-2région et l'identifiant de AWS compte 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 plus d’informations, consultez 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, la date de création du cluster a s3://MyLoggingBucket/MyEMRClusterLogsété spécifiée à 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 plus d’informations, consultez 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 publication 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": "*",
        }
    ]
}