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.
Exemples de politiques d'accès utilisateur pour EMR Serverless
Vous pouvez définir des politiques précises pour vos utilisateurs en fonction des actions que vous souhaitez que chaque utilisateur effectue lorsqu'il interagit avec des applications EMR sans serveur. Les politiques suivantes sont des exemples susceptibles de vous aider à configurer les autorisations appropriées pour vos utilisateurs. Cette section se concentre uniquement sur les politiques EMR sans serveur. Pour des exemples de politiques utilisateur de EMR Studio, voir Configurer les autorisations utilisateur de EMR Studio. Pour plus d'informations sur la manière d'associer des politiques aux IAM utilisateurs (principaux), consultez la section Gestion des IAM politiques dans le Guide de l'IAMutilisateur.
Politique relative aux utilisateurs avancés
Pour accorder toutes les actions requises pour EMR Serverless, créez et associez une AmazonEMRServerlessFullAccess
politique à l'IAMutilisateur, au rôle ou au groupe requis.
Voici un exemple de politique qui permet aux utilisateurs expérimentés de créer et de modifier des applications EMR sans serveur, ainsi que d'effectuer d'autres actions telles que la soumission et le débogage de tâches. Il révèle toutes les actions requises par EMR Serverless pour les autres services.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "EMRServerlessActions", "Effect": "Allow", "Action": [ "emr-serverless:CreateApplication", "emr-serverless:UpdateApplication", "emr-serverless:DeleteApplication", "emr-serverless:ListApplications", "emr-serverless:GetApplication", "emr-serverless:StartApplication", "emr-serverless:StopApplication", "emr-serverless:StartJobRun", "emr-serverless:CancelJobRun", "emr-serverless:ListJobRuns", "emr-serverless:GetJobRun" ], "Resource": "*" } ] }
Lorsque vous activez la connectivité réseau à votreVPC, les applications EMR sans serveur créent des interfaces réseau EC2 élastiques Amazon (ENIs) pour communiquer avec les VPC ressources. La politique suivante garantit que les nouvelles applications ne EC2 ENIs sont créées que dans le contexte des applications EMR sans serveur.
Note
Nous recommandons vivement de définir cette politique afin de garantir que les utilisateurs ne puissent pas créer EC2ENIs, sauf dans le cadre du lancement d'applications EMR sans serveur.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowEC2ENICreationWithEMRTags", "Effect": "Allow", "Action": [ "ec2:CreateNetworkInterface" ], "Resource": [ "arn:aws:ec2:*:*:network-interface/*" ], "Condition": { "StringEquals": { "aws:CalledViaLast": "ops.emr-serverless.amazonaws.com" } } } }
Si vous souhaitez restreindre l'accès EMR sans serveur à certains sous-réseaux, vous pouvez étiqueter chaque sous-réseau avec une condition de balise. Cette IAM politique garantit que les applications EMR sans serveur ne peuvent créer que EC2 ENIs dans les sous-réseaux autorisés.
{ "Sid": "AllowEC2ENICreationInSubnetAndSecurityGroupWithEMRTags", "Effect": "Allow", "Action": [ "ec2:CreateNetworkInterface" ], "Resource": [ "arn:aws:ec2:*:*:subnet/*", "arn:aws:ec2:*:*:security-group/*" ], "Condition": { "StringEquals": { "aws:ResourceTag/
KEY
": "VALUE
" } } }
Important
Si vous êtes un administrateur ou un utilisateur expérimenté qui crée votre première application, vous devez configurer vos politiques d'autorisation pour vous permettre de créer un rôle lié à un service EMR sans serveur. Pour en savoir plus, consultez Utilisation de rôles liés à un service pour Serverless EMR.
La IAM politique suivante vous permet de créer un rôle lié à un service EMR sans serveur pour votre compte.
{ "Sid":"AllowEMRServerlessServiceLinkedRoleCreation", "Effect":"Allow", "Action":"iam:CreateServiceLinkedRole", "Resource":"arn:aws:iam::
account-id
:role/aws-service-role/ops.emr-serverless.amazonaws.com/AWSServiceRoleForAmazonEMRServerless" }
Politique relative aux ingénieurs de données
Voici un exemple de politique qui accorde aux utilisateurs des autorisations en lecture seule sur les applications EMR sans serveur, ainsi que la possibilité de soumettre et de déboguer des tâches. Gardez à l'esprit que, si cette stratégie n'empêche pas explicitement certaines actions, une autre déclaration de stratégie peut toutefois être utilisée pour accorder l'accès aux actions spécifiées.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "EMRServerlessActions", "Effect": "Allow", "Action": [ "emr-serverless:ListApplications", "emr-serverless:GetApplication", "emr-serverless:StartApplication", "emr-serverless:StartJobRun", "emr-serverless:CancelJobRun", "emr-serverless:ListJobRuns", "emr-serverless:GetJobRun" ], "Resource": "*" } ] }
Utilisation de balises pour le contrôle d’accès
Vous pouvez utiliser les conditions des balises pour un contrôle d'accès précis. Par exemple, vous pouvez restreindre les utilisateurs d'une équipe afin qu'ils ne puissent soumettre des tâches qu'aux applications EMR sans serveur étiquetées avec le nom de leur équipe.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "EMRServerlessActions", "Effect": "Allow", "Action": [ "emr-serverless:ListApplications", "emr-serverless:GetApplication", "emr-serverless:StartApplication", "emr-serverless:StartJobRun", "emr-serverless:CancelJobRun", "emr-serverless:ListJobRuns", "emr-serverless:GetJobRun" ], "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceTag/Team": "
team-name
" } } } ] }