View a markdown version of this page

Configuration du rôle IAM - 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.

Configuration du rôle IAM

Conditions préalables

Avant de commencer, assurez-vous de disposer des éléments suivants :

  • Un AWS compte avec accès administratif IAM

  • AWS CLI installée et configurée. Pour plus d'informations, consultez la section Installation de la AWS CLI.

Définissez les variables suivantes à utiliser dans les commandes suivantes :

ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) REGION=$(aws configure get region)

Étape 1 : création du rôle IAM

Le serveur SMUS MCP utilise votre rôle IAM pour autoriser les opérations au niveau du AWS service. Aucune MCP-specific autorisation distincte n'est requise.

Pour créer le rôle IAM (AWS CLI)

  1. Créez un document de politique de confiance qui permet à votre compte d'assumer le rôle suivant :

    cat > mcp-trust-policy.json << EOF { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowAccountToAssumeRole", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::${ACCOUNT_ID}:root" }, "Action": "sts:AssumeRole" } ] } EOF
  2. Créez le rôle :

    aws iam create-role \ --role-name SparkTroubleshootingMCPRole \ --assume-role-policy-document file://mcp-trust-policy.json

Étape 2 : associer des autorisations pour votre mode de déploiement

Joignez la politique d'autorisation qui correspond à votre plateforme de déploiement Spark. Vous pouvez joindre un ou plusieurs des éléments suivants en fonction des plateformes que vous utilisez.

Option A : EMR sur EC2

  1. Créez le document de politique :

    cat > emr-ec2-policy.json << 'EOF' { "Version": "2012-10-17", "Statement": [ { "Sid": "EMREC2ReadAccess", "Effect": "Allow", "Action": [ "elasticmapreduce:DescribeCluster", "elasticmapreduce:DescribeStep", "elasticmapreduce:ListSteps", "elasticmapreduce:ListClusters", "elasticmapreduce:DescribeJobFlows" ], "Resource": ["*"] }, { "Sid": "EMRS3LogAccess", "Effect": "Allow", "Action": ["s3:GetObject", "s3:ListBucket"], "Resource": "*" }, { "Sid": "EMRPersistentApp", "Effect": "Allow", "Action": [ "elasticmapreduce:CreatePersistentAppUI", "elasticmapreduce:DescribePersistentAppUI", "elasticmapreduce:GetPersistentAppUIPresignedURL" ], "Resource": ["*"] } ] } EOF
  2. Créez et attachez la politique :

    aws iam put-role-policy \ --role-name SparkTroubleshootingMCPRole \ --policy-name EMREC2TroubleshootingAccess \ --policy-document file://emr-ec2-policy.json

Vous pouvez également joindre la politique AmazonElasticMapReduceFullAccess AWS gérée si votre rôle l'utilise déjà :

aws iam attach-role-policy \ --role-name SparkTroubleshootingMCPRole \ --policy-arn arn:aws:iam::aws:policy/AmazonElasticMapReduceFullAccess

Option B : AWS Glue

  1. Créez le document de politique :

    cat > glue-policy.json << EOF { "Version": "2012-10-17", "Statement": [ { "Sid": "GlueReadAccess", "Effect": "Allow", "Action": [ "glue:GetJob", "glue:GetJobRun", "glue:GetJobRuns", "glue:GetJobs", "glue:BatchGetJobs" ], "Resource": ["arn:aws:glue:*:${ACCOUNT_ID}:job/*"] }, { "Sid": "GlueCloudWatchLogsAccess", "Effect": "Allow", "Action": ["logs:GetLogEvents", "logs:FilterLogEvents"], "Resource": ["arn:aws:logs:*:${ACCOUNT_ID}:log-group:/aws/glue/*"] }, { "Sid": "GlueSparkWebUI", "Effect": "Allow", "Action": [ "glue:RequestLogParsing", "glue:GetLogParsingStatus", "glue:GetEnvironment", "glue:GetStage", "glue:GetStages", "glue:GetStageFiles", "glue:BatchGetStageFiles", "glue:GetStageAttempt", "glue:GetStageAttemptTaskList", "glue:GetStageAttemptTaskSummary", "glue:GetExecutors", "glue:GetExecutorsThreads", "glue:GetStorage", "glue:GetStorageUnit", "glue:GetQueries", "glue:GetQuery", "glue:GetDashboardUrl" ], "Resource": ["arn:aws:glue:*:${ACCOUNT_ID}:job/*"] }, { "Sid": "GluePassRoleAccess", "Effect": "Allow", "Action": "iam:PassRole", "Resource": "*", "Condition": { "StringLike": { "iam:PassedToService": "glue.amazonaws.com" } } } ] } EOF
  2. Joignez la politique :

    aws iam put-role-policy \ --role-name SparkTroubleshootingMCPRole \ --policy-name GlueTroubleshootingAccess \ --policy-document file://glue-policy.json

Option C : EMR sans serveur

  1. Créez le document de politique :

    cat > emr-serverless-policy.json << EOF { "Version": "2012-10-17", "Statement": [ { "Sid": "EMRServerlessReadAccess", "Effect": "Allow", "Action": [ "emr-serverless:GetJobRun", "emr-serverless:GetApplication", "emr-serverless:ListApplications", "emr-serverless:ListJobRuns", "emr-serverless:ListJobRunAttempts", "emr-serverless:GetDashboardForJobRun", "emr-serverless:ListTagsForResource" ], "Resource": ["*"] }, { "Sid": "EMRServerlessCloudWatchLogsAccess", "Effect": "Allow", "Action": ["logs:GetLogEvents", "logs:FilterLogEvents"], "Resource": ["arn:aws:logs:*:${ACCOUNT_ID}:log-group:/aws/emr-serverless/*"] }, { "Sid": "EMRServerlessS3LogsAccess", "Effect": "Allow", "Action": ["s3:GetObject", "s3:ListBucket"], "Resource": "*" } ] } EOF
  2. Joignez la politique :

    aws iam put-role-policy \ --role-name SparkTroubleshootingMCPRole \ --policy-name EMRServerlessTroubleshootingAccess \ --policy-document file://emr-serverless-policy.json

Facultatif : autorisations KMS pour les CloudWatch journaux chiffrés

Si vos CloudWatch journaux sont chiffrés à l'aide d'une clé KMS gérée par le client, ajoutez ce qui suit (remplacez-la <KEY_ID> par votre ID de clé KMS) :

aws iam put-role-policy \ --role-name SparkTroubleshootingMCPRole \ --policy-name KMSCloudWatchLogsDecrypt \ --policy-document "{ \"Version\": \"2012-10-17\", \"Statement\": [{ \"Effect\": \"Allow\", \"Action\": [\"kms:Decrypt\", \"kms:DescribeKey\"], \"Resource\": \"arn:aws:kms:${REGION}:${ACCOUNT_ID}:key/<KEY_ID>\" }] }"

Étape 3 : Configuration de votre client MCP

Configurez votre client MCP (par exemple, Claude Desktop ou Amazon Q Developer) pour utiliser le rôle ARN que vous avez créé :

echo "arn:aws:iam::${ACCOUNT_ID}:role/SparkTroubleshootingMCPRole"

Reportez-vous à la documentation de votre client MCP pour savoir comment configurer les AWS informations d'identification (généralement via un AWS profil qui assume ce rôle).

Clés de condition pour les demandes du serveur MCP

Deux clés de condition sont automatiquement ajoutées à toutes les demandes effectuées via le serveur SMUS MCP :

  • aws:ViaAWSMCPService— Paramétré sur true pour toute demande effectuée via un serveur MCP AWS géré.

  • aws:CalledViaAWSMCP— Défini sur le principal de service du serveur MCP (par exemple,sagemaker-unified-studio-mcp.amazonaws.com).

Vous pouvez utiliser ces clés de condition pour contrôler l'accès à vos ressources lorsque les demandes proviennent d'un serveur MCP AWS géré.

Exemple : Autoriser les opérations de lecture de Glue uniquement en cas d'accès via le serveur SMUS MCP :

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowGlueReadViaSMUSMCP", "Effect": "Allow", "Action": ["glue:GetJob", "glue:GetJobRun", "glue:GetJobRuns"], "Resource": "*", "Condition": { "StringEquals": { "aws:CalledViaAWSMCP": "sagemaker-unified-studio-mcp.amazonaws.com" } } } ] }

Exemple : refuser les opérations de suppression en cas d'accès via un serveur MCP AWS géré :

{ "Effect": "Deny", "Action": ["s3:DeleteObject", "s3:DeleteBucket"], "Resource": "*", "Condition": { "Bool": { "aws:ViaAWSMCPService": "true" } } }

Pour plus d'informations sur les clés de condition, consultez la section clés contextuelles de condition AWS globales dans le guide de l'utilisateur IAM.