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ôles IAM pour une intégration native avec Apache Ranger
L'intégration entre Amazon EMR et Apache Ranger repose sur trois rôles clés que vous devez créer avant de lancer votre cluster :
+ Un profil d'instance Amazon EC2 personnalisé pour Amazon EMR
+ Un rôle IAM pour les moteurs Apache Ranger
+ Un rôle IAM pour les autres services AWS
Cette section présente ces rôles et les stratégies que vous devez inclure pour chaque rôle IAM. Pour plus d'informations sur la création de ces rôles, consultez [Configurer un serveur d'administration Ranger pour l'intégrer à Amazon EMR](emr-ranger-admin.md).
# profil d'instance EC2 pour Amazon EMR
Amazon EMR utilise un rôle de service IAM pour effectuer des actions en votre nom afin d'allouer et de gérer les clusters. 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 attribué à chaque instance EC2 d'un cluster au moment du lancement.
Pour définir les autorisations d'interaction du cluster EMR avec les données Amazon S3 et avec le métastore Hive protégé par Apache Ranger et d'autres AWS services, définissez un profil d'instance EC2 personnalisé à utiliser à la place du `EMR_EC2_DefaultRole` profil lorsque vous lancez votre cluster.
Pour plus d’informations, consultez [Rôle de service pour les instances EC2 de cluster (profil d'instance EC2)](emr-iam-role-for-ec2.md) et [Personnalisez les rôles IAM avec Amazon EMR](emr-iam-roles-custom.md).
Vous devez ajouter les instructions suivantes au profil d'instance EC2 par défaut pour qu'Amazon EMR puisse baliser les sessions et accéder à celles qui stockent AWS Secrets Manager les certificats TLS.
```
{
"Sid": "AllowAssumeOfRolesAndTagging",
"Effect": "Allow",
"Action": ["sts:TagSession", "sts:AssumeRole"],
"Resource": [
"arn:aws:iam:::role/",
"arn:aws:iam:::role/"
]
},
{
"Sid": "AllowSecretsRetrieval",
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": [
"arn:aws:secretsmanager:::secret:*",
"arn:aws:secretsmanager:::secret:*"
]
}
```
**Note**
Pour les autorisations du Secrets Manager, n'oubliez pas le caractère générique (« \$1 ») à la fin du nom du secret, sinon vos demandes échoueront. Le caractère générique est destiné aux versions secrètes.
**Note**
Limitez le champ d'application de la AWS Secrets Manager politique aux seuls certificats requis pour le provisionnement.
# Rôle IAM pour Apache Ranger
Ce rôle fournit des informations d'identification aux moteurs d'exécution fiables, tels qu'Apache Hive et Amazon EMR Record Server, pour accéder aux données Amazon S3. Utilisez uniquement ce rôle pour accéder aux données Amazon S3, y compris les clés KMS, si vous utilisez S3 SSE-KMS.
Ce rôle doit être créé avec la politique minimale indiquée dans l'exemple suivant.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "CloudwatchLogsPermissions",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Effect": "Allow",
"Resource": [
"arn:aws:logs:*:123456789012:log-group:CLOUDWATCH_LOG_GROUP_NAME_IN_SECURITY_CONFIGURATION:*"
]
},
{
"Sid": "BucketPermissionsInS3Buckets",
"Action": [
"s3:CreateBucket",
"s3:DeleteBucket",
"s3:ListAllMyBuckets",
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket1",
"arn:aws:s3:::amzn-s3-demo-bucket2"
]
},
{
"Sid": "ObjectPermissionsInS3Objects",
"Action": [
"s3:GetObject",
"s3:DeleteObject",
"s3:PutObject"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket1/*",
"arn:aws:s3:::amzn-s3-demo-bucket2/*"
]
}
]
}
```
------
**Important**
L'astérisque « \$1 » à la fin de la ressource de CloudWatch journal doit être inclus pour autoriser l'écriture dans les flux de journaux.
**Note**
Si vous utilisez la vue de cohérence EMRFS ou le chiffrement S3-SSE, ajoutez des autorisations aux tables DynamoDB et aux clés KMS afin que les moteurs d'exécution puissent interagir avec ces moteurs.
Le rôle IAM pour Apache Ranger est assumé par le rôle de profil d'instance EC2. Utilisez l'exemple suivant pour créer une politique d'approbation qui permet au rôle IAM pour Apache Ranger d'être assumé par le rôle de profil d'instance EC2.
```
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam:::role/"
},
"Action": ["sts:AssumeRole", "sts:TagSession"]
}
```
# Rôle IAM pour les autres AWS services d'intégration d'Amazon EMR
Ce rôle fournit aux utilisateurs qui ne sont pas des moteurs d'exécution fiables des informations d'identification leur permettant d'interagir avec AWS les services, si nécessaire. N'utilisez pas ce rôle IAM pour autoriser l'accès aux données Amazon S3, sauf s'il s'agit de données qui devraient être accessibles à tous les utilisateurs.
Ce rôle sera assumé par le rôle de profil d'instance EC2. Utilisez l'exemple suivant pour créer une politique d'approbation qui permet au rôle IAM pour Apache Ranger d'être assumé par le rôle de profil d'instance EC2.
```
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam:::role/"
},
"Action": ["sts:AssumeRole", "sts:TagSession"]
}
```
# Validez vos autorisations pour l'intégration d'Amazon EMR à Apache Ranger
Consultez [Résolution des problèmes liés à Apache](emr-ranger-troubleshooting.md) pour des instructions relatives à la validation des autorisations.