Introducción a los roles de tiempo de ejecución para los pasos de Amazon EMR: utilice los roles de IAM y la formación de lagos de AWS para el control de acceso con Amazon EMR

Puede utilizar el EMR de Amazon API de pasos para enviar Apache Hive, Apache Spark y otros tipos de aplicaciones a un clúster de EMR. Puede invocar la API de pasos usando Apache Airflow, Funciones de pasos de AWS, el Interfaz de línea de comandos de AWS (AWS CLI), todos los SDK de AWS y el Consola de administración de AWS. Los trabajos enviados con la API de pasos utilizan el Nube informática elástica de Amazon (Amazon EC2) perfil de instancia para acceder a los recursos de AWS, como Servicio de almacenamiento simple de Amazon (Amazon S3) baldes, Pegamento AWS tablas, y Amazon DynamoDB tablas del clúster.

Anteriormente, si un paso necesitaba acceso a un depósito de S3 específico y otro paso necesitaba acceso a una tabla específica de DynamoDB, el Gestión de identidades y accesos de AWS (IAM) adjunta al perfil de la instancia tenía que permitir el acceso tanto al depósito S3 como a la tabla de DynamoDB. Esto significaba que las políticas de IAM que asignó al perfil de la instancia debían contener una unión de todos los permisos para cada paso que se ejecutaba en un clúster de EMR.

Nos complace presentar roles de tiempo de ejecución para los pasos de EMR. Un rol de tiempo de ejecución es un rol de IAM que asocia con un paso de EMR, y los trabajos usan este rol para acceder a los recursos de AWS. Con los roles de tiempo de ejecución para los pasos de EMR, ahora puede especificar diferentes roles de IAM para los trabajos de Spark y Hive, limitando así el acceso a nivel de trabajo. Esto le permite simplificar los controles de acceso en un solo clúster de EMR que se comparte entre múltiples inquilinos, donde cada inquilino se puede aislar fácilmente mediante roles de IAM.

La capacidad de especificar un rol de IAM con un trabajo también está disponible en Amazon EMR en EKS y Amazon EMR sin servidor. También puedes usar Formación del lago AWS para aplicar permisos de nivel de tabla y columna para trabajos de Apache Hive y Apache Spark que se envían con pasos de EMR. Para obtener más información, consulte Configurar roles de tiempo de ejecución para los pasos de Amazon EMR.

En esta publicación, profundizamos en los roles de tiempo de ejecución para los pasos de EMR, ayudándolo a comprender cómo funcionan juntas las distintas piezas y cómo se aísla cada paso en un clúster de EMR.

Resumen de la solución

En esta publicación, analizamos lo siguiente:

Cree un clúster de EMR habilitado para usar el nuevo control de acceso basado en roles con pasos de EMR.
Cree dos roles de IAM con diferentes permisos en términos de los datos de Amazon S3 y las tablas de Lake Formation a las que pueden acceder.
Permita que la entidad principal de IAM envíe los pasos de EMR para usar estos dos roles de IAM.
Vea cómo los pasos de EMR que se ejecutan con el mismo código y tratan de acceder a los mismos datos tienen diferentes permisos según el rol de tiempo de ejecución especificado en el momento del envío.
Vea cómo monitorear y controlar acciones usando la propagación de identidad de origen.

Configurar la configuración de seguridad del clúster de EMR

Configuraciones de seguridad de Amazon EMR simplifique la aplicación de opciones coherentes de seguridad, autorización y autenticación en sus clústeres. Puede crear una configuración de seguridad en la consola de Amazon EMR o mediante la AWS CLI o el SDK de AWS. Cuando asocia una configuración de seguridad a un clúster, Amazon EMR aplica la configuración de la configuración de seguridad al clúster. Puede adjuntar una configuración de seguridad a varios clústeres en el momento de la creación, pero no puede aplicarlos a un clúster en ejecución.

Para habilitar los roles de tiempo de ejecución para los pasos de EMR, debemos crear una configuración de seguridad como se muestra en el siguiente código y habilitar la propiedad de roles de tiempo de ejecución (configurada a través de EnableApplicationScopedIAMRole). Además de los roles de tiempo de ejecución, estamos habilitando la propagación de la identidad de origen (configurada a través de PropagateSourceIdentity) y soporte para Lake Formation (configurado a través de LakeFormationConfiguration). La identidad de origen es un mecanismo para monitorear y controlar las acciones realizadas con los roles asumidos. Habilitación Propagar la identidad de la fuente le permite auditar las acciones realizadas con el rol de tiempo de ejecución. Lake Formation es un servicio de AWS para administrar de forma segura un lago de datos, lo que incluye definir y aplicar políticas de control de acceso central para su lago de datos.

Crea un archivo llamado step-runtime-roles-sec-cfg.json con el siguiente contenido:

{
    "AuthorizationConfiguration": {
        "IAMConfiguration": {
            "EnableApplicationScopedIAMRole": true,
            "ApplicationScopedIAMRoleConfiguration": 
                {
                    "PropagateSourceIdentity": true
                }
        },
        "LakeFormationConfiguration": {
            "AuthorizedSessionTagValue": "Amazon EMR"
        }
    }
}

Cree la configuración de seguridad de Amazon EMR:

aws emr create-security-configuration 
--name 'iamconfig-with-iam-lf' 
--security-configuration file://step-runtime-roles-sec-cfg.json

También puede hacer lo mismo a través de la consola de Amazon:

En la consola de Amazon EMR, elija Configuraciones de seguridad en el panel de navegación.
Elige Crear.
Elige Crear.
Nombre de la configuración de seguridad, ingresa un nombre.
Opciones de configuración de configuración de seguridad, seleccione Elija configuraciones personalizadas.
Rol de IAM para aplicaciones, seleccione Rol de tiempo de ejecución.
Seleccione Propagar la identidad de la fuente para auditar las acciones realizadas con el rol de tiempo de ejecución.
Control de acceso detallado, seleccione Formación del lago AWS.
Complete la configuración de seguridad.

La configuración de seguridad aparece en su lista de configuración de seguridad. También puede ver que el mecanismo de autorización que se muestra aquí es el rol de tiempo de ejecución en lugar del perfil de instancia.

Lanzar el clúster

Ahora lanzamos un clúster EMR y especificamos la configuración de seguridad que creamos. Para obtener más información, consulte Especificar una configuración de seguridad para un clúster.

El siguiente código proporciona el comando de la AWS CLI para lanzar un clúster de EMR con la configuración de seguridad adecuada. Tenga en cuenta que este clúster se lanza en la VPC predeterminada y la subred pública con los roles de IAM predeterminados. Además, el clúster se lanza con una instancia principal y una principal del tipo de instancia especificado. Para obtener más detalles sobre cómo personalizar los parámetros de lanzamiento, consulte crear-cluster.

Si los roles EMR predeterminados EMR_EC2_DefaultRole y EMR_DefaultRole no existen en IAM en su cuenta (esta es la primera vez que lanza un clúster de EMR con ellos), antes de lanzar el clúster, use el siguiente comando para crearlos:

aws emr create-default-roles

Cree el clúster con el siguiente código:

#Change with your Key Pair
KEYPAIR=
INSTANCE_TYPE="r4.4xlarge"
#Change with your Security Configuration Name
SECURITY_CONFIG="iamconfig-with-iam-lf"
#Change with your S3 log URI
LOG_URI="s3://mybucket/logs/"

aws emr create-cluster 
--name "iam-passthrough-cluster" 
--release-label emr-6.7.0 
--use-default-roles 
--security-configuration $SECURITY_CONFIG 
--ec2-attributes KeyName=$KEYPAIR 
--instance-groups InstanceGroupType=MASTER,InstanceCount=1,InstanceType=$INSTANCE_TYPE  InstanceGroupType=CORE,InstanceCount=1,InstanceType=$INSTANCE_TYPE 
--applications Name=Spark Name=Hadoop Name=Hive 
--log-uri $LOG_URI

Cuando el clúster está totalmente aprovisionado (Waiting estado), intentemos ejecutar un paso en él con roles de tiempo de ejecución para pasos de EMR habilitados:

#Change with your EMR cluster ID
CLUSTER_ID=j-XXXXXXXXXXXXX
aws emr add-steps 
--cluster-id $CLUSTER_ID 
--steps '[{
            "Type": "CUSTOM_JAR",
            "ActionOnFailure": "CONTINUE",
            "Jar": "command-runner.jar",
            "Name": "Spark Example",
            "Args": [
              "spark-submit",
              "--class",
              "org.apache.spark.examples.SparkPi",
              "/usr/lib/spark/examples/jars/spark-examples.jar",
              "5"
            ]
        }]'

Después de ejecutar el comando, recibimos lo siguiente como resultado:

An error occurred (ValidationException) when calling the AddJobFlowSteps operation: Runtime roles are required for this cluster. Please specify the role using the ExecutionRoleArn parameter.

El paso falló, pidiéndonos que proporcionemos un rol de tiempo de ejecución. En la siguiente sección, configuramos dos roles de IAM con diferentes permisos y los usamos como roles de tiempo de ejecución para los pasos de EMR.

Configurar roles de IAM como roles de tiempo de ejecución

Cualquier función de IAM que desee utilizar como función de tiempo de ejecución para los pasos de EMR debe tener una política de confianza que permita que el perfil de instancia EC2 del clúster de EMR la asuma. En nuestra configuración, usamos el rol de IAM predeterminado EMR_EC2_DefaultRole como rol de perfil de instancia. Además, creamos dos roles de IAM llamados test-emr-demo1 y test-emr-demo2 que usamos como roles de tiempo de ejecución para los pasos de EMR.

El siguiente código es la política de confianza para ambos roles de IAM, lo que permite que el rol de perfil de instancia EC2 del clúster de EMR, EMR_EC2_DefaultRole, asumir estos roles y establecer la identidad de origen y LakeFormationAuthorizedCaller etiqueta en las sesiones de rol. los TagSession se necesita permiso para que Amazon EMR pueda autorizar Lake Formation. los SetSourceIdentity Se necesita una declaración para la característica de identidad de fuente de propagación.

Crea un archivo llamado trust-policy.json con el siguiente contenido (reemplazar 123456789012 con su ID de cuenta de AWS):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:role/EMR_EC2_DefaultRole"
            },
            "Action": "sts:AssumeRole"
        },
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:role/EMR_EC2_DefaultRole"
            },
            "Action": "sts:SetSourceIdentity"
        },
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:role/EMR_EC2_DefaultRole"
            },
            "Action": "sts:TagSession",
            "Condition": {
                "StringEquals": {
                    "aws:RequestTag/LakeFormationAuthorizedCaller": "Amazon EMR"
                }
            }
        }
    ]
}

Use esa política para crear los dos roles de IAM, test-emr-demo1 y test-emr-demo2:

aws iam create-role 
--role-name test-emr-demo1 
--assume-role-policy-document file://trust-policy.json

aws iam create-role 
--role-name test-emr-demo2 
--assume-role-policy-document file://trust-policy.json

Configurar permisos para el principal que envía los pasos de EMR con roles de tiempo de ejecución

La entidad principal de IAM que envía los pasos de EMR debe tener permisos para invocar el API AddJobFlowSteps. Además, puede utilizar la tecla Condición elasticmapreduce:ExecutionRoleArn para controlar el acceso a funciones específicas de IAM. Por ejemplo, la siguiente política permite que la entidad principal de IAM solo use roles de IAM test-emr-demo1 y test-emr-demo2 como los roles de tiempo de ejecución para los pasos de EMR.

Crea el job-submitter-policy.json archivo con el siguiente contenido (reemplazar 123456789012 con su ID de cuenta de AWS):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AddStepsWithSpecificExecRoleArn",
            "Effect": "Allow",
            "Action": [
                "elasticmapreduce:AddJobFlowSteps"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "elasticmapreduce:ExecutionRoleArn": [
                        "arn:aws:iam::123456789012:role/test-emr-demo1",
                        "arn:aws:iam::123456789012:role/test-emr-demo2"
                    ]
                }
            }
        },
        {
            "Sid": "EMRDescribeCluster",
            "Effect": "Allow",
            "Action": [
                "elasticmapreduce:DescribeCluster"
            ],
            "Resource": "*"
        }
    ]
}

Cree la política de IAM con el siguiente código:

aws iam create-policy 
--policy-name emr-runtime-roles-submitter-policy 
--policy-document file://job-submitter-policy.json

Asigne esta política a la entidad principal de IAM (usuario de IAM o rol de IAM) que utilizará para enviar los pasos de EMR (reemplace 123456789012 con su ID de cuenta de AWS y reemplace john con el usuario de IAM que utiliza para enviar sus pasos de EMR):
```
aws iam attach-user-policy 
--user-name john 
--policy-arn "arn:aws:iam::123456789012:policy/emr-runtime-roles-submitter-policy"
```

Usuario de IAM john ahora puede enviar pasos usando arn:aws:iam::123456789012:role/test-emr-demo1 y arn:aws:iam::123456789012:role/test-emr-demo2 como los roles de tiempo de ejecución del paso.

Use roles de tiempo de ejecución con pasos de EMR

Ahora preparamos nuestra configuración para mostrar los roles de tiempo de ejecución para los pasos de EMR en acción.

Configurar Amazon S3

Para preparar sus datos de Amazon S3, complete los siguientes pasos:

Cree un archivo CSV llamado test.csv con el siguiente contenido:
```
1,a,1a
2,b,2b
```

Suba el archivo a Amazon S3 en tres ubicaciones diferentes:

#Change this with your bucket name
BUCKET_NAME="emr-steps-roles-new-us-east-1"

aws s3 cp test.csv s3://${BUCKET_NAME}/demo1/
aws s3 cp test.csv s3://${BUCKET_NAME}/demo2/
aws s3 cp test.csv s3://${BUCKET_NAME}/nondemo/

Para nuestra prueba inicial, usamos una aplicación PySpark llamada test.py con los siguientes contenidos:

from pyspark.sql import SparkSession
spark = SparkSession.builder.appName("my app").enableHiveSupport().getOrCreate()

#Change this with your bucket name
BUCKET_NAME="emr-steps-roles-new-us-east-1"

try:
  spark.read.csv("s3://" + BUCKET_NAME + "/demo1/test.csv").show()
  print("Accessed demo1")
except:
  print("Could not access demo1")

try:
  spark.read.csv("s3://" + BUCKET_NAME + "/demo2/test.csv").show()
  print("Accessed demo2")
except:
  print("Could not access demo2")

try:
  spark.read.csv("s3://" + BUCKET_NAME + "/nondemo/test.csv").show()
  print("Accessed nondemo")
except:
  print("Could not access nondemo")
spark.stop()

En la secuencia de comandos, intentamos acceder al archivo CSV presente en tres prefijos diferentes en el depósito de prueba.

Cargue la aplicación Spark dentro del mismo depósito S3 donde colocamos el test.csv archivo pero en una ubicación diferente:

#Change this with your bucket name
BUCKET_NAME="emr-steps-roles-new-us-east-1"
aws s3 cp test.py s3://${BUCKET_NAME}/scripts/

Configurar permisos de roles de tiempo de ejecución

Para mostrar cómo funcionan los roles de tiempo de ejecución para los pasos de EMR, asignamos a los roles que creamos diferentes permisos de IAM para acceder a Amazon S3. La siguiente tabla resume las subvenciones que otorgamos a cada rol (emr-steps-roles-new-us-east-1 es el depósito que configuró en la sección anterior).

Funciones de IAM de las ubicaciones de S3	prueba-emr-demo1	prueba-emr-demo2
s3://emr-steps-roles-nuevo-este-de-ee-uu-1/*	Sin acceso	Sin acceso
s3://emr-steps-roles-new-us-east-1/demo1/*	Acceso Completo	Sin acceso
s3://emr-steps-roles-new-us-east-1/demo2/*	Sin acceso	Acceso Completo
s3://emr-steps-roles-new-us-east-1/scripts/*	Leer acceso	Leer acceso

Crea el archivo demo1-policy.json con el siguiente contenido (sustituir emr-steps-roles-new-us-east-1 con el nombre de su cubo):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:*"
            ],
            "Resource": [
                "arn:aws:s3:::emr-steps-roles-new-us-east-1/demo1",
                "arn:aws:s3:::emr-steps-roles-new-us-east-1/demo1/*"
            ]                    
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:Get*"
            ],
            "Resource": [
                "arn:aws:s3:::emr-steps-roles-new-us-east-1/scripts",
                "arn:aws:s3:::emr-steps-roles-new-us-east-1/scripts/*"
            ]                    
        }
    ]
}

Crea el archivo demo2-policy.json con el siguiente contenido (sustituir emr-steps-roles-new-us-east-1 con el nombre de su cubo):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:*"
            ],
            "Resource": [
                "arn:aws:s3:::emr-steps-roles-new-us-east-1/demo2",
                "arn:aws:s3:::emr-steps-roles-new-us-east-1/demo2/*"
            ]                    
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:Get*"
            ],
            "Resource": [
                "arn:aws:s3:::emr-steps-roles-new-us-east-1/scripts",
                "arn:aws:s3:::emr-steps-roles-new-us-east-1/scripts/*"
            ]                    
        }
    ]
}

Crea nuestras políticas de IAM:

aws iam create-policy 
--policy-name test-emr-demo1-policy 
--policy-document file://demo1-policy.json

aws iam create-policy 
--policy-name test-emr-demo2-policy 
--policy-document file://demo2-policy.json

Asigne a cada rol la política relacionada (reemplazar 123456789012 con su ID de cuenta de AWS):
```
aws iam attach-role-policy 
--role-name test-emr-demo1 
--policy-arn "arn:aws:iam::123456789012:policy/test-emr-demo1-policy"

aws iam attach-role-policy 
--role-name test-emr-demo2 
--policy-arn "arn:aws:iam::123456789012:policy/test-emr-demo2-policy"
```
Para usar roles de tiempo de ejecución con los pasos de Amazon EMR, debemos agregar la siguiente política al perfil de instancia EC2 de nuestro clúster de EMR (en este ejemplo EMR_EC2_DefaultRole). Con esta política, las instancias EC2 subyacentes para el clúster de EMR pueden asumir el rol de tiempo de ejecución y aplicar una etiqueta a ese rol de tiempo de ejecución.

Crea el archivo runtime-roles-policy.json con el siguiente contenido (reemplazar 123456789012 con su ID de cuenta de AWS):

{
    "Version": "2012-10-17",
    "Statement": [{
            "Sid": "AllowRuntimeRoleUsage",
            "Effect": "Allow",
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession",
                "sts:SetSourceIdentity"
            ],
            "Resource": [
                "arn:aws:iam::123456789012:role/test-emr-demo1",
                "arn:aws:iam::123456789012:role/test-emr-demo2"
            ]
        }
    ]
}

Cree la política de IAM:

aws iam create-policy 
--policy-name emr-runtime-roles-policy 
--policy-document file://runtime-roles-policy.json

Asigne la política creada al perfil de instancia EC2 del clúster de EMR, en este ejemplo EMR_EC2_DefaultRole:

aws iam attach-role-policy 
--role-name EMR_EC2_DefaultRole 
--policy-arn "arn:aws:iam::123456789012:policy/emr-runtime-roles-policy"

Probar permisos con roles de tiempo de ejecución

Ahora estamos listos para realizar nuestra primera prueba. ejecutamos el test.py script, previamente cargado en Amazon S3, dos veces como pasos de Spark: primero usando el test-emr-demo1 rol y luego usando el test-emr-demo2 rol como los roles de tiempo de ejecución.

Para ejecutar un paso de EMR que especifique un rol de tiempo de ejecución, necesita la versión más reciente de la CLI de AWS. Para obtener más detalles sobre la actualización de la CLI de AWS, consulte Instalación o actualización de la última versión de la AWS CLI.

Vamos a enviar un paso especificando test-emr-demo1 como el rol de tiempo de ejecución:

#Change with your EMR cluster ID
CLUSTER_ID=j-XXXXXXXXXXXXX
#Change with your AWS Account ID
ACCOUNT_ID=123456789012
#Change with your Bucket name
BUCKET_NAME=emr-steps-roles-new-us-east-1

aws emr add-steps 
--cluster-id $CLUSTER_ID 
--steps '[{
            "Type": "CUSTOM_JAR",
            "ActionOnFailure": "CONTINUE",
            "Jar": "command-runner.jar",
            "Name": "Spark Example",
            "Args": [
              "spark-submit",
              "s3://'"${BUCKET_NAME}"'/scripts/test.py"
            ]
        }]' 
--execution-role-arn arn:aws:iam::${ACCOUNT_ID}:role/test-emr-demo1

Este comando devuelve un ID de paso de EMR. Para verificar nuestros registros de salida de pasos, podemos proceder de dos maneras diferentes:

Desde la consola de Amazon EMR - Sobre el pasos pestaña, elija el Ver los registros enlace relacionado con el ID de paso específico y seleccione stdout.
Desde Amazon S3 – Al lanzar nuestro clúster, configuramos una ubicación S3 para iniciar sesión. Podemos encontrar nuestros registros de pasos en $(LOG_URI)/steps//stdout.gz.

Los registros pueden tardar un par de minutos en completarse después de marcar el paso como Completed.

El siguiente es el resultado del paso EMR con test-emr-demo1 como el rol de tiempo de ejecución:

+---+---+---+
|_c0|_c1|_c2|
+---+---+---+
|  1|  a| 1a|
|  2|  b| 2b|
+---+---+---+

Accessed demo1
Could not access demo2
Could not access nondemo

Como podemos ver, sólo el demo1 Nuestra aplicación pudo acceder a la carpeta.

Profundizando en el paso stderr logs, podemos ver que la aplicación YARN relacionada application_1656350436159_0017 fue lanzado con el usuario 6GC64F33KUW4Q2JY6LKR7UAHWETKKXYL. Podemos confirmar esto por conectarse a la instancia principal de EMR mediante SSH y usando el HILO CLI:

[hadoop@ip-172-31-63-203]$ yarn application -status application_1656350436159_0017
...
Application-Id : application_1656350436159_0017
Application-Name : my app
Application-Type : SPARK
User : 6GC64F33KUW4Q2JY6LKR7UAHWETKKXYL
Queue : default
Application Priority : 0
...

Tenga en cuenta que, en su caso, la identificación de la aplicación YARN y el usuario serán diferentes.

Ahora volvemos a enviar el mismo script como un nuevo paso de EMR, pero esta vez con el rol test-emr-demo2 como el rol de tiempo de ejecución:

#Change with your EMR cluster ID
CLUSTER_ID=j-XXXXXXXXXXXXX
#Change with your AWS Account ID
ACCOUNT_ID=123456789012
#Change with your Bucket name
BUCKET_NAME=emr-steps-roles-new-us-east-1

aws emr add-steps 
--cluster-id $CLUSTER_ID 
--steps '[{
            "Type": "CUSTOM_JAR",
            "ActionOnFailure": "CONTINUE",
            "Jar": "command-runner.jar",
            "Name": "Spark Example",
            "Args": [
              "spark-submit",
              "s3://'"${BUCKET_NAME}"'/scripts/test.py"
            ]
        }]' 
--execution-role-arn arn:aws:iam::${ACCOUNT_ID}:role/test-emr-demo2

El siguiente es el resultado del paso EMR con test-emr-demo2 como el rol de tiempo de ejecución:

Could not access demo1
+---+---+---+
|_c0|_c1|_c2|
+---+---+---+
|  1|  a| 1a|
|  2|  b| 2b|
+---+---+---+

Accessed demo2
Could not access nondemo

Como podemos ver, sólo el demo2 Nuestra aplicación pudo acceder a la carpeta.

Profundizando en el paso stderr logs, podemos ver que la aplicación YARN relacionada application_1656350436159_0018 fue lanzado con un usuario diferente 7T2ORHE6Z4Q7PHLN725C2CVWILZWYOLE. Podemos confirmar esto usando la CLI de YARN:

[hadoop@ip-172-31-63-203]$ yarn application -status application_1656350436159_0018
...
Application-Id : application_1656350436159_0018
Application-Name : my app
Application-Type : SPARK
User : 7T2ORHE6Z4Q7PHLN725C2CVWILZWYOLE
Queue : default
Application Priority : 0
...

Cada paso solo pudo acceder al archivo CSV permitido por el rol de tiempo de ejecución, por lo que el primer paso solo pudo acceder s3://emr-steps-roles-new-us-east-1/demo1/test.csv y el segundo paso solo fue capaz de acceder s3://emr-steps-roles-new-us-east-1/demo2/test.csv. Además, observamos que Amazon EMR creó un usuario único para los pasos y utilizó al usuario para ejecutar los trabajos. Tenga en cuenta que ambos roles necesitan al menos acceso de lectura a la ubicación de S3 donde se encuentran los scripts de pasos (por ejemplo, s3://emr-steps-roles-demo-bucket/scripts/test.py).

Ahora que hemos visto cómo funcionan los roles de tiempo de ejecución para los pasos de EMR, veamos cómo podemos usar Lake Formation para aplicar controles de acceso detallados con pasos de EMR.

Use el control de acceso basado en Lake Formation con pasos de EMR

Puede usar Lake Formation para aplicar permisos de nivel de tabla y columna con trabajos de Apache Spark y Apache Hive enviados como pasos de EMR. Primero, el administrador del lago de datos en Lake Formation debe registrarse Amazon EMR como el AuthorizedSessionTagValue para hacer cumplir los permisos de Lake Formation en EMR. Lake Formation usa esta etiqueta de sesión para autorizar a las personas que llaman y proporcionar acceso al lago de datos. los Amazon EMR se hace referencia al valor dentro del step-runtime-roles-sec-cfg.json que usamos anteriormente cuando creamos la configuración de seguridad de EMR, y dentro del trust-policy.json archivo que usamos para crear los dos roles de tiempo de ejecución test-emr-demo1 y test-emr-demo2.

Podemos hacerlo en la consola de Lake Formation en el Filtrado de datos externos sección (reemplazar 123456789012 con su ID de cuenta de AWS).

En la política de confianza de los roles de tiempo de ejecución de IAM, ya tenemos la sts:TagSession permiso con la condición “aws:RequestTag/LakeFormationAuthorizedCaller": "Amazon EMR". Así que estamos listos para continuar.

Para demostrar cómo funciona Lake Formation con los pasos de EMR, creamos una base de datos llamada entities con dos tablas nombradas users y products, y asignamos en Formación Lago las mercedes resumidas en la siguiente tabla.

Tablas de roles de IAM	entidades (DB)
Tablas de roles de IAM	usuarios (Mesa)	productos (Mesa)
prueba-emr-demo1	Acceso de lectura completo	Sin acceso
prueba-emr-demo2	Acceso de lectura en columnas: uid, estado	Acceso de lectura completo

Preparar archivos de Amazon S3

Primero preparamos nuestros archivos de Amazon S3.

Crea el users.csv Archivo con el siguiente contenido:

00005678,john,pike,england,london,Hidden Road 78
00009039,paolo,rossi,italy,milan,Via degli Alberi 56A
00009057,july,finn,germany,berlin,Green Road 90

Cree el archivo products.csv con el siguiente contenido:

P0000789,Bike2000,Sport
P0000567,CoverToCover,Smartphone
P0005677,Whiteboard X786,Home

Cargue estos archivos en Amazon S3 en dos ubicaciones diferentes:

#Change this with your bucket name
BUCKET_NAME="emr-steps-roles-new-us-east-1"

aws s3 cp users.csv s3://${BUCKET_NAME}/entities-database/users/
aws s3 cp products.csv s3://${BUCKET_NAME}/entities-database/products/

Preparar la base de datos y las tablas.

Podemos crear nuestro entities base de datos utilizando el API de pegamento de AWS.

Crea el entities-db.json archivo con el siguiente contenido (sustituir emr-steps-roles-new-us-east-1 con el nombre de su depósito):

{
    "DatabaseInput": {
        "Name": "entities",
        "LocationUri": "s3://emr-steps-roles-new-us-east-1/entities-database/",
        "CreateTableDefaultPermissions": []
    }
}

Con un usuario administrador de Lake Formation, ejecute el siguiente comando para crear nuestra base de datos:
```
aws glue create-database 
--cli-input-json file://entities-db.json
```
También utilizamos las API de AWS Glue para crear las tablas de usuarios y productos.

Crea el users-table.json archivo con el siguiente contenido (sustituir emr-steps-roles-new-us-east-1 con el nombre de su cubo):

{
    "TableInput": {
        "Name": "users",
        "StorageDescriptor": {
            "Columns": [{
                    "Name": "uid",
                    "Type": "string"
                },
                {
                    "Name": "name",
                    "Type": "string"
                },
                {
                    "Name": "surname",
                    "Type": "string"
                },
                {
                    "Name": "state",
                    "Type": "string"
                },
                {
                    "Name": "city",
                    "Type": "string"
                },
                {
                    "Name": "address",
                    "Type": "string"
                }
            ],
            "Location": "s3://emr-steps-roles-new-us-east-1/entities-database/users/",
            "InputFormat": "org.apache.hadoop.mapred.TextInputFormat",
            "OutputFormat": "org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat",
            "Compressed": false,
            "SerdeInfo": {
                "SerializationLibrary": "org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe",
                "Parameters": {
                    "field.delim": ",",
                    "serialization.format": ","
                }
            }
        },
        "TableType": "EXTERNAL_TABLE",
        "Parameters": {
            "EXTERNAL": "TRUE"
        }
    }
}

Crea el products-table.json archivo con el siguiente contenido (sustituir emr-steps-roles-new-us-east-1 con el nombre de su cubo):

{
    "TableInput": {
        "Name": "products",
        "StorageDescriptor": {
            "Columns": [{
                    "Name": "product_id",
                    "Type": "string"
                },
                {
                    "Name": "name",
                    "Type": "string"
                },
                {
                    "Name": "category",
                    "Type": "string"
                }
            ],
            "Location": "s3://emr-steps-roles-new-us-east-1/entities-database/products/",
            "InputFormat": "org.apache.hadoop.mapred.TextInputFormat",
            "OutputFormat": "org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat",
            "Compressed": false,
            "SerdeInfo": {
                "SerializationLibrary": "org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe",
                "Parameters": {
                    "field.delim": ",",
                    "serialization.format": ","
                }
            }
        },
        "TableType": "EXTERNAL_TABLE",
        "Parameters": {
            "EXTERNAL": "TRUE"
        }
    }
}

Con un usuario administrador de Lake Formation, cree nuestras tablas con los siguientes comandos:

aws glue create-table 
    --database-name entities 
    --cli-input-json file://users-table.json
    
aws glue create-table 
    --database-name entities 
    --cli-input-json file://products-table.json

Configurar las ubicaciones del lago de datos de Lake Formation

Para acceder a los datos de nuestras tablas en Amazon S3, Lake Formation necesita acceso de lectura/escritura. Para lograrlo, debemos registrar las ubicaciones de Amazon S3 donde residen nuestros datos y especificarles de qué rol de IAM obtener las credenciales.

Vamos a crear nuestro rol de IAM para el acceso a los datos.

Crea un archivo llamado trust-policy-data-access-role.json con el siguiente contenido:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
                "Service": "lakeformation.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

Utilice la política para crear el IAM role emr-demo-lf-data-access-role:

aws iam create-role 
--role-name emr-demo-lf-data-access-role 
--assume-role-policy-document file://trust-policy-data-access-role.json

Crea el archivo data-access-role-policy.json con el siguiente contenido (sustituir emr-steps-roles-new-us-east-1 con el nombre de su cubo):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:*"
            ],
            "Resource": [
                "arn:aws:s3:::emr-steps-roles-new-us-east-1/entities-database",
                "arn:aws:s3:::emr-steps-roles-new-us-east-1/entities-database/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::emr-steps-roles-new-us-east-1"
            ]
        }
    ]
}

Crea nuestra política de IAM:

aws iam create-policy 
--policy-name data-access-role-policy 
--policy-document file://data-access-role-policy.json

Asignar a nuestro emr-demo-lf-data-access-role la política creada (reemplazar 123456789012 con su ID de cuenta de AWS):
```
aws iam attach-role-policy 
--role-name emr-demo-lf-data-access-role 
--policy-arn "arn:aws:iam::123456789012:policy/data-access-role-policy"
```
Ahora podemos registrar nuestra ubicación de datos en Lake Formation.
En la consola de Lake Formation, elija Ubicaciones de data lake en el panel de navegación.
Aquí podemos registrar nuestra ubicación S3 que contiene datos para nuestras dos tablas y elegir la creada emr-demo-lf-data-access-role Rol de IAM, que tiene acceso de lectura/escritura a esa ubicación.

Para obtener más detalles sobre cómo agregar una ubicación de Amazon S3 a su lago de datos y configurar sus funciones de acceso a datos de IAM, consulte Agregar una ubicación de Amazon S3 a su lago de datos.

Hacer cumplir los permisos de formación de lagos

Para asegurarnos de que estamos usando los permisos de Lake Formation, debemos confirmar que no tenemos ninguna concesión configurada para el director IAMAllowedPrincipals. IAMAllowedPrincipals El grupo incluye todos los usuarios y funciones de IAM a los que sus políticas de IAM permiten el acceso a los recursos de Data Catalog y se utiliza para mantener la compatibilidad con versiones anteriores de AWS Glue.

Para confirmar que se aplican los permisos de Lake Formations, vaya a la consola de Lake Formations y elija Permisos del lago de datos en el panel de navegación. Filtrar permisos por “Database”:“entities” y eliminar todos los permisos otorgados al principal IAMAllowedPrincipals.

Para más detalles sobre IAMAllowedPrincipals y compatibilidad con versiones anteriores de AWS Glue, consulte Cambiar la configuración de seguridad predeterminada para su lago de datos.

Configurar concesiones de AWS Glue y Lake Formation para roles de tiempo de ejecución de IAM

Para permitir que nuestros roles de tiempo de ejecución de IAM interactúen correctamente con Lake Formation, debemos proporcionarles la lakeformation:GetDataAccess y glue:Get* subsidios.

Los permisos de Lake Formation controlan el acceso a los recursos de Data Catalog, las ubicaciones de Amazon S3 y los datos subyacentes en esas ubicaciones. Los permisos de IAM controlan el acceso a las API y los recursos de Lake Formation y AWS Glue. Por lo tanto, aunque es posible que tenga el permiso de Lake Formation para acceder a una tabla en Data Catalog (SELECT), su operación falla si no tiene el permiso de IAM en el glue:Get* API.

Para obtener más detalles sobre el control de acceso de Lake Formation, consulte Descripción general del control de acceso de Lake Formation.

Crea el emr-runtime-roles-lake-formation-policy.json Archivo con el siguiente contenido:

{
    "Version": "2012-10-17",
    "Statement": {
        "Sid": "LakeFormationManagedAccess",
        "Effect": "Allow",
        "Action": [
            "lakeformation:GetDataAccess",
            "glue:Get*",
            "glue:Create*",
            "glue:Update*"
        ],
        "Resource": "*"
    }
}

Cree la política de IAM relacionada:

aws iam create-policy 
--policy-name emr-runtime-roles-lake-formation-policy 
--policy-document file://emr-runtime-roles-lake-formation-policy.json

Asigne esta política a ambos roles de tiempo de ejecución de IAM (reemplace 123456789012 con su ID de cuenta de AWS):

aws iam attach-role-policy 
--role-name test-emr-demo1 
--policy-arn "arn:aws:iam::123456789012:policy/emr-runtime-roles-lake-formation-policy"

aws iam attach-role-policy 
--role-name test-emr-demo2 
--policy-arn "arn:aws:iam::123456789012:policy/emr-runtime-roles-lake-formation-policy"

Configurar permisos de formación de lagos

Ahora configuramos el permiso en Lake Formation para los dos roles de tiempo de ejecución.

Crea el archivo users-grants-test-emr-demo1.json con el siguiente contenido para otorgar acceso SELECT a todas las columnas en el entities.users mesa para test-emr-demo1:

{
    "Principal": {
        "DataLakePrincipalIdentifier": "arn:aws:iam::123456789012:role/test-emr-demo1"
    },
    "Resource": {
        "Table": {
            "DatabaseName": "entities",
            "Name": "users"
        }
    },
    "Permissions": [
        "SELECT"
    ]
}

Crea el archivo users-grants-test-emr-demo2.json con el siguiente contenido para otorgar acceso SELECT a la uid y state columnas en el entities.users mesa para test-emr-demo2:

{
    "Principal": {
        "DataLakePrincipalIdentifier": "arn:aws:iam::123456789012:role/test-emr-demo2"
    },
    "Resource": {
        "TableWithColumns": {
            "DatabaseName": "entities",
            "Name": "users",
            "ColumnNames": ["uid", "state"]
        }
    },
    "Permissions": [
        "SELECT"
    ]
}

Crea el archivo products-grants-test-emr-demo2.json con el siguiente contenido para otorgar acceso SELECT a todas las columnas en el entities.products mesa para test-emr-demo2:

{
    "Principal": {
        "DataLakePrincipalIdentifier": "arn:aws:iam::123456789012:role/test-emr-demo2"
    },
    "Resource": {
        "Table": {
            "DatabaseName": "entities",
            "Name": "products"
        }
    },
    "Permissions": [
        "SELECT"
    ]
}

Configuremos nuestros permisos en Lake Formation:

aws lakeformation grant-permissions 
--cli-input-json file://users-grants-test-emr-demo1.json

aws lakeformation grant-permissions 
--cli-input-json file://users-grants-test-emr-demo2.json

aws lakeformation grant-permissions 
--cli-input-json file://products-grants-test-emr-demo2.json

Verifique los permisos que definimos en la consola de Lake Formation en el Permisos del lago de datos página filtrando por “Database”:“entities”.

Probar los permisos de Lake Formation con roles de tiempo de ejecución

Para nuestra prueba, usamos una aplicación PySpark llamada test-lake-formation.py con el siguiente contenido:


from pyspark.sql import SparkSession
 
spark = SparkSession.builder.appName("Pyspark - TEST IAM RBAC with LF").enableHiveSupport().getOrCreate()

try:
    print("== select * from entities.users limit 3 ==n")
    spark.sql("select * from entities.users limit 3").show()
except Exception as e:
    print(e)

try:
    print("== select * from entities.products limit 3 ==n")
    spark.sql("select * from entities.products limit 3").show()
except Exception as e:
    print(e)

spark.stop()

En el script, estamos tratando de acceder a las tablas. users y products. Carguemos nuestra aplicación Spark en el mismo depósito S3 que usamos anteriormente:

#Change this with your bucket name
BUCKET_NAME="emr-steps-roles-new-us-east-1"

aws s3 cp test-lake-formation.py s3://${BUCKET_NAME}/scripts/

Ahora estamos listos para realizar nuestra prueba. ejecutamos el test-lake-formation.py script primero usando el test-emr-demo1 rol y luego usando el test-emr-demo2 rol como los roles de tiempo de ejecución.

Vamos a enviar un paso especificando test-emr-demo1 como el rol de tiempo de ejecución:

#Change with your EMR cluster ID
CLUSTER_ID=j-XXXXXXXXXXXXX
#Change with your AWS Account ID
ACCOUNT_ID=123456789012
#Change with your Bucket name
BUCKET_NAME=emr-steps-roles-new-us-east-1

aws emr add-steps 
--cluster-id $CLUSTER_ID 
--steps '[{
            "Type": "CUSTOM_JAR",
            "ActionOnFailure": "CONTINUE",
            "Jar": "command-runner.jar",
            "Name": "Spark Lake Formation Example",
            "Args": [
              "spark-submit",
              "s3://'"${BUCKET_NAME}"'/scripts/test-lake-formation.py"
            ]
        }]' 
--execution-role-arn arn:aws:iam::${ACCOUNT_ID}:role/test-emr-demo1

El siguiente es el resultado del paso EMR con test-emr-demo1 como el rol de tiempo de ejecución:

== select * from entities.users limit 3 ==

+--------+-----+-------+-------+------+--------------------+
|     uid| name|surname|  state|  city|             address|
+--------+-----+-------+-------+------+--------------------+
|00005678| john|   pike|england|london|      Hidden Road 78|
|00009039|paolo|  rossi|  italy| milan|Via degli Alberi 56A|
|00009057| july|   finn|germany|berlin|       Green Road 90|
+--------+-----+-------+-------+------+--------------------+

== select * from entities.products limit 3 ==

Insufficient Lake Formation permission(s) on products (...)

Como podemos ver, nuestra aplicación solo pudo acceder a la users mesa.

Vuelva a enviar el mismo script como un nuevo paso de EMR, pero esta vez con el rol test-emr-demo2 como el rol de tiempo de ejecución:

#Change with your EMR cluster ID
CLUSTER_ID=j-XXXXXXXXXXXXX
#Change with your AWS Account ID
ACCOUNT_ID=123456789012
#Change with your Bucket name
BUCKET_NAME=emr-steps-roles-new-us-east-1

aws emr add-steps 
--cluster-id $CLUSTER_ID 
--steps '[{
            "Type": "CUSTOM_JAR",
            "ActionOnFailure": "CONTINUE",
            "Jar": "command-runner.jar",
            "Name": "Spark Lake Formation Example",
            "Args": [
              "spark-submit",
              "s3://'"${BUCKET_NAME}"'/scripts/test-lake-formation.py"
            ]
        }]' 
--execution-role-arn arn:aws:iam::${ACCOUNT_ID}:role/test-emr-demo2

El siguiente es el resultado del paso EMR con test-emr-demo2 como el rol de tiempo de ejecución:

== select * from entities.users limit 3 ==

+--------+-------+
|     uid|  state|
+--------+-------+
|00005678|england|
|00009039|  italy|
|00009057|germany|
+--------+-------+

== select * from entities.products limit 3 ==

+----------+---------------+----------+
|product_id|           name|  category|
+----------+---------------+----------+
|  P0000789|       Bike2000|     Sport|
|  P0000567|   CoverToCover|Smartphone|
|  P0005677|Whiteboard X786|      Home|
+----------+---------------+----------+

Como podemos ver, nuestra aplicación pudo acceder a un subconjunto de columnas para el users tabla y todas las columnas para el products mesa.

Podemos concluir que los permisos al acceder al catálogo de datos se aplican en función del rol de tiempo de ejecución utilizado con el paso EMR.

Auditoría utilizando la identidad de origen

El proyecto identidad de origen es un mecanismo para monitorear y controlar las acciones realizadas con los roles asumidos. los Propagar la identidad de la fuente La función le permite monitorear y controlar las acciones realizadas mediante roles de tiempo de ejecución por los trabajos enviados con los pasos de EMR.

ya lo configuramos EMR_EC2_defaultRole "sts:SetSourceIdentity" en nuestros dos roles de tiempo de ejecución. Además, ambos roles de tiempo de ejecución permiten EMR_EC2_DefaultRole a SetSourceIdentity en su política de confianza. Así que estamos listos para continuar.

Ahora vemos el Propagar la identidad de la fuente característica en acción con un ejemplo simple.

Configure el rol de IAM que se asume para enviar los pasos de EMR

Configuramos el rol de IAM job-submitter-1, que se supone que especifica la identidad de origen y que se utiliza para enviar los pasos de EMR. En este ejemplo, permitimos que el usuario de IAM paul para asumir este rol y establecer la identidad de origen. Tenga en cuenta que puede utilizar cualquier principal de IAM aquí.

Crea un archivo llamado trust-policy-2.json con el siguiente contenido (reemplazar 123456789012 con su ID de cuenta de AWS):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:user/paul"
            },
            "Action": "sts:AssumeRole"
        },
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:user/paul"
            },
            "Action": "sts:SetSourceIdentity"
        }
    ]
}

Úselo como política de confianza para crear el rol de IAM job-submitter-1:
```
aws iam create-role 
--role-name job-submitter-1 
--assume-role-policy-document file://trust-policy-2.json
```
Usamos ahora lo mismo emr-runtime-roles-submitter-policy política que definimos antes para permitir que el rol envíe pasos de EMR usando el test-emr-demo1 y test-emr-demo2 roles de tiempo de ejecución.

Asigne esta política al rol de IAM job-submitter-1 (reemplazar 123456789012 con su ID de cuenta de AWS):

aws iam attach-role-policy 
--role-name job-submitter-1 
--policy-arn "arn:aws:iam::123456789012:policy/emr-runtime-roles-submitter-policy"

Pruebe la identidad de origen con AWS CloudTrail

Para mostrar cómo funciona la propagación de la identidad de origen con Amazon EMR, generamos una sesión de rol con la identidad de origen test-ad-user.

Con el usuario de IAM paul (o con el principal de IAM que configuró), primero realizamos la suplantación (reemplazar 123456789012 con su ID de cuenta de AWS):

aws sts assume-role 
--role-arn arn:aws:iam::123456789012:role/job-submitter-1 
--role-session-name demotest 
--source-identity test-ad-user

El siguiente código es el resultado recibido:

{
"Credentials": {
    "SecretAccessKey": "",
    "SessionToken": "",
    "Expiration": "",
    "AccessKeyId": ""
},
"AssumedRoleUser": {
    "AssumedRoleId": "AROAUVT2HQ3......:demotest",
    "Arn": "arn:aws:sts::123456789012:assumed-role/test-emr-role/demotest"
},
"SourceIdentity": "test-ad-user"
}

Usamos las credenciales de seguridad temporales de AWS de la sesión de rol para enviar un paso de EMR junto con el rol de tiempo de ejecución. test-emr-demo1:

export AWS_ACCESS_KEY_ID=""
export AWS_SECRET_ACCESS_KEY=""
export AWS_SESSION_TOKEN="" 

#Change with your EMR cluster ID
CLUSTER_ID=j-XXXXXXXXXXXXX
#Change with your AWS Account ID
ACCOUNT_ID=123456789012
#Change with your Bucket name
BUCKET_NAME=emr-steps-roles-new-us-east-1

aws emr add-steps 
--cluster-id $CLUSTER_ID 
--steps '[{
            "Type": "CUSTOM_JAR",
            "ActionOnFailure": "CONTINUE",
            "Jar": "command-runner.jar",
            "Name": "Spark Lake Formation Example",
            "Args": [
              "spark-submit",
              "s3://'"${BUCKET_NAME}"'/scripts/test-lake-formation.py"
            ]
        }]' 
--execution-role-arn arn:aws:iam::${ACCOUNT_ID}:role/test-emr-demo1

En unos minutos, podemos ver los eventos que aparecen en el Seguimiento de la nube de AWS archivo de registro. Podemos ver todas las API de AWS que invocaron los trabajos mediante el rol de tiempo de ejecución. En el siguiente fragmento, podemos ver que el paso realizó el sts:AssumeRole y lakeformation:GetDataAccess comportamiento. Vale la pena señalar cómo la identidad de origen test-ad-user se ha conservado en los acontecimientos.

Limpiar

Ahora puede eliminar el clúster de EMR que creó.

En la consola de Amazon EMR, elija Clusters en el panel de navegación.
Seleccione el clúster iam-passthrough-cluster, A continuación, elija Terminar.
Elige Terminar de nuevo para confirmar

Como alternativa, puede eliminar el clúster mediante la CLI de Amazon EMR con el siguiente comando (reemplace el ID del clúster de EMR con el que devolvió la ejecución anterior). aws emr create-cluster mando):

aws emr terminate-clusters --cluster-ids j-3KVXXXXXXX7UG

Conclusión

En esta publicación, discutimos cómo puede controlar el acceso a los datos en Amazon EMR en clústeres de EC2 mediante el uso de roles de tiempo de ejecución con pasos de EMR. Discutimos cómo funciona la función, cómo puede usar Lake Formation para aplicar controles de acceso detallados y cómo monitorear y controlar acciones usando una identidad de origen. Para obtener más información sobre esta característica, consulte Configurar roles de tiempo de ejecución para los pasos de Amazon EMR.

Sobre los autores

Stefano Sandona es un arquitecto de soluciones especialista en análisis con AWS. Le encantan los datos, los sistemas distribuidos y la seguridad. Ayuda a clientes de todo el mundo a diseñar sus plataformas de datos. Tiene un fuerte enfoque en Amazon EMR y todos los aspectos de seguridad que lo rodean.

sharad kala es un ingeniero sénior en AWS que trabaja con el equipo de EMR. Se centra en los aspectos de seguridad de las aplicaciones que se ejecutan en EMR. Tiene un gran interés en trabajar y aprender sobre sistemas distribuidos.

Inteligencia de datos generativa

Presentación de roles de tiempo de ejecución para los pasos de Amazon EMR: use roles de IAM y AWS Lake Formation para el control de acceso con Amazon EMR