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.

Configurer les rôles IAM d'exécution pour l'accès au EMR cluster Amazon dans Studio

Lorsque vous vous connectez à un EMR cluster Amazon depuis vos blocs-notes Studio ou Studio Classic, vous pouvez parcourir visuellement une liste de IAM rôles, appelés rôles d'exécution, et en sélectionner un à la volée. Par la suite, toutes vos tâches Apache Spark, Apache Hive ou Presto créées à partir de votre bloc-notes accèdent uniquement aux données et aux ressources autorisées par les politiques associées au rôle d'exécution. En outre, lorsque les données sont accessibles à partir de lacs de données gérés avec AWS Lake Formation, vous pouvez appliquer l'accès au niveau des tables et des colonnes à l'aide de politiques associées au rôle d'exécution.

Grâce à cette fonctionnalité, vous et vos collègues pouvez vous connecter au même cluster, chacun utilisant un rôle d'exécution assorti d'autorisations correspondant à votre niveau individuel d'accès aux données. Vos sessions sont également isolées les unes des autres sur le cluster partagé.

Pour tester cette fonctionnalité à l'aide de Studio Classic, consultez Appliquer des contrôles d'accès aux données précis avec AWS Lake Formation Amazon SageMaker Studio Classic et EMR Amazon. Ce billet de blog vous aide à configurer un environnement de démonstration dans lequel vous pouvez essayer d'utiliser des rôles d'exécution préconfigurés pour vous connecter aux EMR clusters Amazon.

Prérequis

Avant de démarrer, assurez-vous de répondre aux conditions préalables suivantes :

Scénarios de connexion entre comptes

L'authentification des rôles d'exécution prend en charge divers scénarios de connexion entre comptes lorsque vos données se trouvent en dehors de votre compte Studio. L'image suivante montre trois manières différentes d'attribuer votre EMR cluster Amazon, vos données et même votre rôle EMR d'exécution Amazon Runtime entre votre compte Studio et vos comptes de données :

Dans l'option 1, votre EMR cluster Amazon et votre rôle EMR d'exécution Amazon Runtime se trouvent dans un compte de données distinct du compte Studio. Vous définissez un rôle d'EMRaccès Amazon distinct (également appeléAssumable role) politique d'autorisation qui autorise le rôle d'exécution Studio ou Studio Classic à assumer le rôle EMR d'accès Amazon. Le rôle EMR d'accès Amazon appelle ensuite Amazon EMR API GetClusterSessionCredentials au nom de votre rôle d'exécution Studio ou Studio Classic pour vous donner accès au cluster.

Dans l'option 2, votre EMR cluster Amazon et votre rôle EMR d'exécution Amazon Runtime se trouvent dans votre compte Studio. Votre rôle d'exécution Studio est autorisé à utiliser Amazon EMR API GetClusterSessionCredentials pour accéder à votre cluster. Pour accéder au compartiment Amazon S3, accordez au rôle EMR d'exécution Amazon Runtime des autorisations d'accès au compartiment Amazon S3 entre comptes. Vous accordez ces autorisations dans le cadre de votre politique de compartiment Amazon S3.

Dans l'option 3, vos EMR clusters Amazon se trouvent dans votre compte Studio et le rôle EMR d'exécution Amazon Runtime se trouve dans le compte de données. Votre rôle d'exécution Studio ou Studio Classic est autorisé à utiliser Amazon EMR API GetClusterSessionCredentials pour accéder à votre cluster. Ajoutez le rôle EMR d'exécution Amazon Runtime dans la configuration du rôle d'exécutionJSON. Vous pouvez ensuite sélectionner le rôle dans l'interface utilisateur lorsque vous choisissez votre cluster. Pour plus d'informations sur la configuration du JSON fichier de configuration de votre rôle d'exécution, consultezPréchargez vos rôles d'exécution dans Studio ou Studio Classic.

Configurer Studio pour utiliser des IAM rôles d'exécution

Pour établir l'authentification des rôles d'exécution pour vos EMR clusters Amazon, configurez les IAM politiques, le réseau et les améliorations d'utilisabilité requises. Votre configuration dépend de votre capacité à gérer des arrangements entre comptes si vos EMR clusters Amazon, votre rôle EMR d'exécution Amazon Runtime, ou les deux, se trouvent en dehors de votre compte Studio. La section suivante vous explique les politiques à installer, comment configurer le réseau pour autoriser le trafic entre comptes multiples et le fichier de configuration local à configurer pour automatiser votre EMR connexion Amazon.

Configurez l'authentification des rôles d'exécution lorsque votre EMR cluster Amazon et Studio sont sur le même compte

Si votre EMR cluster Amazon réside dans votre compte Studio, suivez les étapes suivantes pour ajouter les autorisations nécessaires à votre politique d'exécution Studio :

L'exemple de politique suivant autorise les rôles EMR d'exécution d'Amazon Runtime appartenant aux groupes de modélisation et de formation à appelerGetClusterSessionCredentials. En outre, le preneur d'assurance peut accéder aux EMR clusters Amazon étiquetés avec les chaînes modeling outraining.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "elasticmapreduce:GetClusterSessionCredentials",
            "Resource": "*",
            "Condition": {
                "StringLike": {
                    "elasticmapreduce:ExecutionRoleArn": [
                        "arn:aws:iam::123456780910:role/emr-execution-role-ml-modeling*",
                        "arn:aws:iam::123456780910:role/emr-execution-role-ml-training*"
                    ],
                    "elasticmapreduce:ResourceTag/group": [
                        "*modeling*",
                        "*training*"
                    ]
                }
            }
        }
    ]
}

Configuration de l'authentification du rôle d'exécution lorsque votre cluster et Studio sont dans des comptes différents

Configuration de l'accès à Lake Formation

Lorsque vous accédez à des données à partir de lacs de données gérés par AWS Lake Formation, vous pouvez appliquer l'accès au niveau des tables et des colonnes à l'aide des politiques associées à votre rôle d'exécution. Pour configurer l'autorisation d'accès à Lake Formation, consultez Intégrer Amazon EMR à AWS Lake Formation.

Préchargez vos rôles d'exécution dans Studio ou Studio Classic

Vous pouvez précharger vos rôles IAM d'exécution afin de sélectionner le rôle à utiliser lorsque vous vous connectez à votre EMR cluster Amazon. Les utilisateurs d' JupyterLab in Studio peuvent utiliser la SageMaker console ou le script fourni.

Preload runtime roles in JupyterLab using the SageMaker console

Pour associer vos rôles d'exécution à votre profil utilisateur ou à votre domaine à l'aide de la SageMaker console :

1. Accédez à la SageMaker console à l'adresse https://console.aws.amazon.com/sagemaker/.

2. Dans le volet de navigation de gauche, choisissez le domaine, puis sélectionnez le domaine à l'aide du rôle SageMaker d'exécution dont vous avez mis à jour les autorisations.

3. • Pour ajouter votre environnement d'exécution (et vos rôles d'accès pour les cas d'utilisation entre comptes) à votre domaine : dans l'onglet Configurations des applications de la page des détails du domaine, accédez à la JupyterLabsection.

   • Pour ajouter votre environnement d'exécution (et vos rôles d'accès pour les cas d'utilisation entre comptes) à votre profil utilisateur : sur la page Détails du domaine, choisissez l'onglet Profils utilisateur, sélectionnez le profil utilisateur à l'aide du rôle d' SageMaker exécution dont vous avez mis à jour les autorisations. Dans l'onglet Configurations de l'application, accédez à la JupyterLabsection.

4. Choisissez Modifier et ajoutez votre rôle ARNs d'accès (rôle assumé) et les rôles d'exécution d'exécution d'exécution EMR sans serveur.

5. Sélectionnez Envoyer.

Lors de votre prochaine connexion à un EMR serveur Amazon, les rôles d'exécution devraient apparaître dans un menu déroulant pour être sélectionnés.

Preload runtime roles in JupyterLab using a Python script

Dans une JupyterLab application démarrée depuis un espace utilisant le rôle SageMaker d'exécution dont vous avez mis à jour les autorisations, exécutez la commande suivante dans un terminal. Remplacez les valeurs domainID user-profile-nameemr-accountID,, et EMRServiceRole par leurs valeurs appropriées. Cet extrait de code met à jour les paramètres d'un profil utilisateur (client.update_userprofile) au sein d'un SageMaker domaine dans un cas d'utilisation entre comptes. Plus précisément, il définit les rôles de service pour AmazonEMR. Cela permet également à l' JupyterLab application d'assumer un IAM rôle particulier (AssumableRoleouAccessRole) d'exécuter Amazon EMR au sein du EMR compte Amazon.

Vous pouvez également utiliser client.update_domain pour mettre à jour les paramètres du domaine si votre espace utilise un rôle d'exécution défini au niveau du domaine.

import botocore.session
import json
sess = botocore.session.get_session()
client = sess.create_client('sagemaker')

client.update_userprofile(
DomainId="domainID", 
UserProfileName="user-profile-name",
DefaultUserSettings={
    'JupyterLabAppSettings': {
        'EmrSettings': {
            'AssumableRoleArns': ["arn:aws:iam::emr-accountID:role/AssumableRole"],
            'ExecutionRoleArns': ["arn:aws:iam::emr-accountID:role/EMRServiceRole", 
                             "arn:aws:iam::emr-accountID:role/AnotherServiceRole"]
        }
        
    }
})
resp = client.describe_user_profile(DomainId="domainID", UserProfileName=user-profile-name")

resp['CreationTime'] = str(resp['CreationTime'])
resp['LastModifiedTime'] = str(resp['LastModifiedTime'])
print(json.dumps(resp, indent=2))

Preload runtime roles in Studio Classic

Fournissez le ARN of the AccessRole (AssumableRole) à votre rôle SageMaker d'exécution. Le ARN est chargé par le serveur Jupyter au lancement. Le rôle d'exécution utilisé par Studio assume ce rôle entre comptes pour découvrir et se connecter aux EMR clusters Amazon dans le compte de confiance.

Vous pouvez spécifier ces informations à l'aide de scripts Lifecycle Configuration (LCC). Vous pouvez l'associer LCC à votre domaine ou à un profil utilisateur spécifique. Le LCC script que vous utilisez doit être une JupyterServer configuration. Pour plus d'informations sur la création d'un LCC script, voir Utiliser les configurations du cycle de vie avec Studio Classic.

Voici un exemple de LCC script. Pour modifier le script, remplacez AssumableRole et emr-account par leurs valeurs respectives. Le nombre de comptes croisés est limité à cinq.

L'extrait suivant est un exemple de script LCC bash que vous pouvez appliquer si votre application Studio Classic et votre cluster appartiennent au même compte :

#!/bin/bash

set -eux

FILE_DIRECTORY="/home/sagemaker-user/.sagemaker-analytics-configuration-DO_NOT_DELETE"
FILE_NAME="emr-configurations-DO_NOT_DELETE.json"
FILE="$FILE_DIRECTORY/$FILE_NAME"

mkdir -p $FILE_DIRECTORY

cat << 'EOF' > "$FILE"
{
    "emr-execution-role-arns":
    {
      "123456789012": [
          "arn:aws:iam::123456789012:role/emr-execution-role-1",
          "arn:aws:iam::123456789012:role/emr-execution-role-2"
      ]
    }
}
EOF

Si votre application Studio Classic et vos clusters se trouvent dans des comptes différents, spécifiez les rôles EMR d'accès Amazon autorisés à utiliser le cluster. Dans l'exemple de politique suivant, 123456789012 est l'ID du compte du cluster EMR Amazon, et 212121212121 et 434343434343 correspondent aux rôles d'accès Amazon autorisés. ARNs EMR

#!/bin/bash

set -eux

FILE_DIRECTORY="/home/sagemaker-user/.sagemaker-analytics-configuration-DO_NOT_DELETE"
FILE_NAME="emr-configurations-DO_NOT_DELETE.json"
FILE="$FILE_DIRECTORY/$FILE_NAME"

mkdir -p $FILE_DIRECTORY

cat << 'EOF' > "$FILE"
{
    "emr-execution-role-arns":
    {
      "123456789012": [
          "arn:aws:iam::212121212121:role/emr-execution-role-1",
          "arn:aws:iam::434343434343:role/emr-execution-role-2"
      ]
    }
}
EOF

# add your cross-account EMR access role
FILE_DIRECTORY="/home/sagemaker-user/.cross-account-configuration-DO_NOT_DELETE"
FILE_NAME="emr-discovery-iam-role-arns-DO_NOT_DELETE.json"
FILE="$FILE_DIRECTORY/$FILE_NAME"

mkdir -p $FILE_DIRECTORY

cat << 'EOF' > "$FILE"
{
    "123456789012": "arn:aws:iam::123456789012:role/cross-account-emr-access-role"
}
EOF