Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés. # Uso de Amazon EMR en EKS con AWS Lake Formation para un control de acceso detallado Con la versión 7.7 y versiones posteriores de Amazon EMR, puede aprovechar AWS Lake Formation para aplicar controles de acceso detallados en las tablas del catálogo de datos de AWS Glue respaldadas por buckets de Amazon S3. Esta capacidad le permite configurar los controles de acceso a nivel de tabla, fila, columna y celda para las consultas de lectura dentro de sus trabajos de Spark de Amazon EMR en EKS. **Topics** + [Cómo funciona Amazon EMR en EKS con Lake Formation AWS](security_iam_fgac-lf-works.md) + [Habilitación de Lake Formation con Amazon EMR en EKS](security_iam_fgac-lf-enable.md) + [Consideraciones y limitaciones](security_iam_fgac-considerations.md) + [Resolución de problemas](security_iam_fgac-troubleshooting.md) # Cómo funciona Amazon EMR en EKS con Lake Formation AWS El uso de Amazon EMR en EKS con Lake Formation le permite implementar una capa de permisos en cada trabajo de Spark para aplicar el control de permisos de Lake Formation cuando Amazon EMR en EKS ejecuta trabajos. Amazon EMR en EKS utiliza [los perfiles de recursos de Spark](https://spark.apache.org/docs/latest/api/java/org/apache/spark/resource/ResourceProfile.html) para crear dos perfiles a fin de ejecutar los trabajos de forma eficaz. El perfil de usuario ejecuta el código proporcionado por el usuario, mientras que el perfil del sistema implementa las políticas de Lake Formation. Cada trabajo habilitado para Lake Formation utiliza dos controladores Spark, uno para el perfil de usuario y otro para el perfil del sistema. Para obtener más información, consulte What is [AWS Lake Formation](https://docs.aws.amazon.com/lake-formation/latest/dg/what-is-lake-formation.html). A continuación, se ofrece una descripción general de alto nivel sobre cómo Amazon EMR en EKS obtiene acceso a los datos protegidos por las políticas de seguridad de Lake Formation. ![\[Seguridad laboral a través de Lake Formation\]](http://docs.aws.amazon.com/es_es/emr/latest/EMR-on-EKS-DevelopmentGuide/images/fgac_diagram_eks_spark.png) Los siguientes pasos describen este proceso: 1. Un usuario envía un trabajo de Spark a un clúster virtual Amazon EMR en EKS habilitado para AWS Lake Formation. 1. El servicio Amazon EMR en EKS configura el controlador de usuario y ejecuta el trabajo en el perfil de usuario. El controlador de usuario ejecuta una versión sencilla de Spark que no permite lanzar tareas, solicitar ejecutores, acceder a Amazon S3 ni al Catálogo de datos de Glue Solo crea un plan de trabajo. 1. El servicio de Amazon EMR en EKS configura un segundo controlador denominado “controlador del sistema” y lo ejecuta en el perfil del sistema (con una identidad privilegiada). Amazon EKS configura un canal TLS cifrado entre los dos controladores para la comunicación. El controlador de usuario utiliza el canal para enviar los planes de trabajo al controlador del sistema. El controlador del sistema no ejecuta el código enviado por el usuario. Ejecuta Spark a pleno rendimiento y se comunica con Amazon S3 y con el Catálogo de datos para acceder a los datos. Solicita ejecutores y compila el plan de trabajo en una secuencia de etapas de ejecución. 1. Luego, el servicio de Amazon EMR en EKS ejecuta las etapas en los ejecutores. En cualquier etapa, el código de usuario se ejecuta exclusivamente en los ejecutores de perfiles de usuario. 1. Las etapas que leen datos de las tablas del Catálogo de datos protegidas por Lake Formation, o aquellas que aplican filtros de seguridad, se delegan a los ejecutores del sistema. # Habilitación de Lake Formation con Amazon EMR en EKS Con Amazon EMR versión 7.7 y versiones posteriores, puede aprovechar AWS Lake Formation para aplicar controles de acceso detallados en las tablas del catálogo de datos respaldadas por Amazon S3. Esta capacidad le permite configurar los controles de acceso a nivel de tabla, fila, columna y celda para las consultas de lectura dentro de sus trabajos de Spark de Amazon EMR en EKS. En esta sección, explicamos cómo crear una configuración de seguridad y cómo configurar Lake Formation para que funcione con Amazon EMR. También explicamos cómo crear un clúster virtual con la configuración de seguridad que creó para Lake Formation. Estas secciones deben completarse en secuencia. ## Paso 1: configurar permisos a nivel de columna, fila o celda basados en Lake Formation En primer lugar, para aplicar permisos a nivel de fila y columna con Lake Formation, el administrador del lago de datos de Lake Formation debe establecer la etiqueta de **LakeFormationAuthorizedCaller**sesión. Lake Formation usa esta etiqueta de sesión para autorizar a los intermediarios y proporcionar acceso al lago de datos. Navegue a la consola de AWS Lake Formation y seleccione la opción de **configuración de integración de aplicaciones** en la sección **Administración** de la barra lateral. Luego, marque la casilla **Permitir que motores externos filtren datos en las ubicaciones de Amazon S3 registradas en Lake Formation**. Añade la **AWS cuenta en** la que IDs se ejecutarían los trabajos de Spark y los valores de la **etiqueta de sesión**. ![\[Página de integración de aplicaciones\]](http://docs.aws.amazon.com/es_es/emr/latest/EMR-on-EKS-DevelopmentGuide/images/application_integration_settings_fgac.png) Ten en cuenta que la etiqueta de **LakeFormationAuthorizedCaller**sesión que se pasa aquí se incluye **SecurityConfiguration**más adelante cuando configuras las funciones de IAM, en la sección 3. ## Paso 2: configurar los permisos RBAC de EKS A continuación, configurará permisos para control de acceso basado en roles. ### Proporcione permisos de clúster de EKS al servicio de Amazon EMR en EKS El servicio Amazon EMR en EKS debe tener permisos de rol de clúster de EKS para poder crear permisos de espacios de nombres cruzados a fin de que el controlador del sistema genere ejecutores de usuarios en el espacio de nombres del usuario. **Cree su rol del clúster** Esta muestra define los permisos para una colección de recursos. ``` vim emr-containers-cluster-role.yaml --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: emr-containers rules: - apiGroups: [""] resources: ["namespaces"] verbs: ["get"] - apiGroups: [""] resources: ["serviceaccounts", "services", "configmaps", "events", "pods", "pods/log"] verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "deletecollection", "annotate", "patch", "label"] - apiGroups: [""] resources: ["secrets"] verbs: ["create", "patch", "delete", "watch"] - apiGroups: ["apps"] resources: ["statefulsets", "deployments"] verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "annotate", "patch", "label"] - apiGroups: ["batch"] resources: ["jobs"] verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "annotate", "patch", "label"] - apiGroups: ["extensions", "networking.k8s.io"] resources: ["ingresses"] verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "annotate", "patch", "label"] - apiGroups: ["rbac.authorization.k8s.io"] resources: ["clusterroles","clusterrolebindings","roles", "rolebindings"] verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "deletecollection", "annotate", "patch", "label"] - apiGroups: [""] resources: ["persistentvolumeclaims"] verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "deletecollection", "annotate", "patch", "label"] - apiGroups: ["kyverno.io"] resources: ["clusterpolicies"] verbs: ["create", "delete"] --- ``` ``` kubectl apply -f emr-containers-cluster-role.yaml ``` **Cree enlaces de roles de clúster** ``` vim emr-containers-cluster-role-binding.yaml --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: emr-containers subjects: - kind: User name: emr-containers apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: emr-containers apiGroup: rbac.authorization.k8s.io --- ``` ``` kubectl apply -f emr-containers-cluster-role-binding.yaml ``` ### Proporcione acceso de espacio de nombres al servicio de Amazon EMR en EKS Cree dos espacios de nombres de Kubernetes, uno para el controlador de usuario y los ejecutores, y otro para el controlador y los ejecutores del sistema. Habilite el acceso al servicio Amazon EMR en EKS para enviar trabajos en los espacios de nombres de usuario y sistema. Siga la guía existente para proporcionar acceso a cada espacio de nombres, que está disponible en [Enable cluster access using `aws-auth`](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-cluster-access.html#setting-up-cluster-access-aws-auth). ## Paso 3: configurar los roles de IAM para los componentes del perfil de usuario y del sistema En tercer lugar, debe configurar los roles para componentes específicos. Un trabajo de Spark habilitado para Lake Formation tiene dos componentes: usuario y sistema. El controlador de usuario y los ejecutores se ejecutan en el espacio de nombres de usuario y están vinculados al JobExecutionRole que se transfiere a la API. StartJobRun El controlador y los ejecutores del sistema se ejecutan en el espacio de nombres del sistema y están vinculados a la función. **QueryEngine** ### Configure el rol Query Engine El QueryEngine rol está vinculado a los componentes del espacio del sistema y tendría permisos para asumir la etiqueta **JobExecutionRole**with **LakeFormationAuthorizedCaller**Session. La política de permisos de IAM del rol Query Engine es la siguiente: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AssumeJobRoleWithSessionTagAccessForSystemDriver", "Effect": "Allow", "Action": [ "sts:AssumeRole", "sts:TagSession" ], "Resource": [ "arn:aws:iam::*:role/JobExecutionRole" ], "Condition": { "StringLike": { "aws:RequestTag/LakeFormationAuthorizedCaller": "EMR on EKS Engine" } } }, { "Sid": "AssumeJobRoleWithSessionTagAccessForSystemExecutor", "Effect": "Allow", "Action": [ "sts:AssumeRole" ], "Resource": [ "arn:aws:iam::*:role/JobExecutionRole" ] }, { "Sid": "CreateCertificateAccessForTLS", "Effect": "Allow", "Action": [ "emr-containers:CreateCertificate" ], "Resource": [ "*" ] } ] } ``` ------ Configure la política de confianza del rol Query Engine para que confíe en el espacio de nombres del sistema Kubernetes. ``` aws emr-containers update-role-trust-policy \ --cluster-name eks cluster \ --namespace eks system namespace \ --role-name query_engine_iam_role_name ``` Para obtener más información, consulte [Actualización de una política de confianza de rol](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-trust-policy.html). ### Configurar el rol de ejecución de tareas Los permisos de Lake Formation controlan el acceso a los recursos del catálogo de datos de AWS Glue, a las ubicaciones de Amazon S3 y a los datos subyacentes en esas ubicaciones. Los permisos de la IAM controlan el acceso a Lake Formation and AWS Glue APIs y a los recursos. Aunque es posible que tenga el permiso de Lake Formation para acceder a una tabla del Catálogo de datos (SELECT), la operación fallará si no tiene el permiso de IAM en la operativa de la API `glue:Get*`. Política de permisos de IAM de **JobExecutionRole**: El **JobExecution**rol debe incluir las declaraciones de política en su política de permisos. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "GlueCatalogAccess", "Effect": "Allow", "Action": [ "glue:Get*", "glue:Create*", "glue:Update*" ], "Resource": [ "*" ] }, { "Sid": "LakeFormationAccess", "Effect": "Allow", "Action": [ "lakeformation:GetDataAccess" ], "Resource": [ "*" ] }, { "Sid": "CreateCertificateAccessForTLS", "Effect": "Allow", "Action": [ "emr-containers:CreateCertificate" ], "Resource": [ "*" ] } ] } ``` ------ Política de confianza de IAM para: **JobExecutionRole** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "TrustQueryEngineRoleForSystemDriver", "Effect": "Allow", "Action": [ "sts:AssumeRole", "sts:TagSession" ], "Resource": [ "arn:aws:iam::*:role/QueryExecutionRole" ], "Condition": { "StringLike": { "aws:RequestTag/LakeFormationAuthorizedCaller": "EMR on EKS Engine" } } }, { "Sid": "TrustQueryEngineRoleForSystemExecutor", "Effect": "Allow", "Action": [ "sts:AssumeRole" ], "Resource": [ "arn:aws:iam::*:role/QueryEngineRole" ] } ] } ``` ------ Configure el rol de la política de confianza del trabajo para que confíe en el espacio de nombres de usuario de Kubernetes: ``` aws emr-containers update-role-trust-policy \ --cluster-name eks cluster \ --namespace eks User namespace \ --role-name job_execution_role_name ``` Para obtener más información, consulte [Update the trust policy of the job execution role](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-trust-policy.html). ## Paso 4: establecer la configuración de seguridad Para ejecutar un trabajo habilitado para Lake Formation, debe crear una configuración de seguridad. ``` aws emr-containers create-security-configuration \ --name 'security-configuration-name' \ --security-configuration '{ "authorizationConfiguration": { "lakeFormationConfiguration": { "authorizedSessionTagValue": "SessionTag configured in LakeFormation", "secureNamespaceInfo": { "clusterId": "eks-cluster-name", "namespace": "system-namespace-name" }, "queryEngineRoleArn": "query-engine-IAM-role-ARN" } } }' ``` Asegúrese de que la etiqueta de sesión introducida en el campo **authorizedSessionTagValue** pueda autorizar a Lake Formation. Establezca el valor como el configurado en Lake Formation en [Paso 1: configurar permisos a nivel de columna, fila o celda basados en Lake Formation](#security_iam_fgac-lf-enable-permissions). ## Paso 5: crear un clúster virtual Cree un clúster virtual de Amazon EMR en EKS con una configuración de seguridad. ``` aws emr-containers create-virtual-cluster \ --name my-lf-enabled-vc \ --container-provider '{ "id": "eks-cluster", "type": "EKS", "info": { "eksInfo": { "namespace": "user-namespace" } } }' \ --security-configuration-id SecurityConfiguraionId ``` Asegúrese de pasar el **SecurityConfiguration**ID del paso anterior para que la configuración de autorización de Lake Formation se aplique a todos los trabajos que se ejecutan en el clúster virtual. Para obtener más información, consulte [Register the Amazon EKS cluster with Amazon EMR](). ## Paso 6: Enviar un trabajo en el FGAC Enabled VirtualCluster El proceso de presentación de trabajos es el mismo tanto para los trabajos que son de Lake Formation como los que no lo son. Para obtener más información, consulte [Submit a job run with `StartJobRun`](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-submit.html). El controlador Spark, el ejecutor y los registros de eventos del controlador del sistema se almacenan en el depósito S3 de la cuenta de AWS servicio para su depuración. Recomendamos configurar una clave KMS administrada por el cliente en Job Run para cifrar todos los registros almacenados en el AWS depósito de servicio. Para obtener más información sobre cómo habilitar el cifrado de registros, consulte [Encrypting Amazon EMR on EKS logs](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/security_iam_fgac-logging-kms.html). # Consideraciones y limitaciones Tenga en cuenta las siguientes consideraciones y limitaciones cuando utilice Lake Formation con Amazon EMR en EKS: + Amazon EMR en EKS admite un control de acceso detallado a través de Lake Formation solo para las tablas de Apache Hive, Apache Iceberg, Apache Hud y Delta. Los formatos de Apache Hive incluyen Parquet, ORC y xSV. + `DynamicResourceAllocation` está habilitado de forma predeterminada, no puede deshabilitar `DynamicResourceAllocation` para los trabajos de Lake formation. Como el valor predeterminado de la configuración DRA `spark.dynamicAllocation.maxExecutors` es infinito, configure un valor adecuado en función de su carga de trabajo. + Los trabajos habilitados para Lake Formation no admiten el uso de EMR personalizado en imágenes EKS con los controladores y ejecutores de sistema. + Solo puede utilizar Lake Formation con trabajos de Spark. + EMR en EKS con Lake Formation solo admite una única sesión de Spark durante un trabajo. + EMR en EKS con Lake Formation solo admite consultas de tablas entre cuentas compartidas a través de enlaces de recursos. + Lo siguiente no es compatible: + Conjuntos de datos distribuidos resilientes (RDD) + Streaming de Spark + Lectura con permisos concedidos de Lake Formation + Control de acceso para columnas anidadas + EMR en EKS bloquea las funcionalidades que podrían socavar el aislamiento total del controlador del sistema, incluidas las siguientes: + UDTs, Hive UDFs y cualquier función definida por el usuario que incluya clases personalizadas + Orígenes de datos personalizados + Suministro de archivos jar adicionales para la extensión, el conector o el comando de metalmacén `ANALYZE TABLE` de Spark + Para hacer cumplir los controles de acceso, `EXPLAIN PLAN` y las operaciones de DDL, como `DESCRIBE TABLE`, no exponen información restringida. + Amazon EMR en EKS restringe el acceso a los registros de Spark del controlador del sistema en los trabajos habilitados para Lake Formation. Dado que el controlador del sistema se ejecuta con más acceso, los eventos y registros que genera el controlador del sistema pueden incluir información confidencial. Para evitar que usuarios o códigos no autorizados accedan a esta información confidencial, EMR en EKS deshabilitó el acceso a los registros de los controladores del sistema. Para solucionar problemas, ponte en contacto con AWS el servicio de asistencia. + Si ha registrado una ubicación de tabla en Lake Formation, la ruta de acceso a los datos pasa por las credenciales almacenadas de Lake Formation, independientemente del permiso de IAM para el rol de ejecución de trabajos de EMR en EKS. Si configura incorrectamente el rol registrado con la ubicación de la tabla, los trabajos enviados que usen el rol con permisos de IAM de S3 para la ubicación de la tabla fallarán. + Para escribir en una tabla de Lake Formation se utiliza el permiso de IAM en lugar de los permisos concedidos por Lake Formation. Si el rol de ejecución de su trabajo tiene los permisos de S3 necesarios, puede usarlo para ejecutar operaciones de escritura. A continuación, se indican las consideraciones y limitaciones cuando se utiliza Apache Iceberg: + Solo puede usar Apache Iceberg con el catálogo de sesiones y no con catálogos con nombres arbitrarios. + Las tablas de Iceberg que están registradas en Lake Formation solo admiten las tablas de metadatos `history`, `metadata_log_entries`, `snapshots`, `files`, `manifests` y `refs`. Amazon EMR oculta las columnas que pueden contener datos confidenciales, como `partitions`, `path` y `summaries`. Esta limitación no se aplica a las tablas de Iceberg que no estén registradas en Lake Formation. + Las tablas que no se registran en Lake Formation admiten todos los procedimientos almacenados de Iceberg. Los procedimientos `register_table` y `migrate` no son compatibles con ninguna tabla. + Le recomendamos que utilice Iceberg DataFrameWriter V2 en lugar de V1. Para obtener más información, consulte [Understanding Amazon EMR on EKS concepts and terminology](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-concepts.html) y [Enable cluster access for Amazon EMR on EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-cluster-access.html). ## Exención de responsabilidad para los administradores de datos **nota** Al conceder acceso a los recursos de Lake Formation a un rol de IAM para EMR en EKS, debe asegurarse de que el administrador u operador del clúster de EMR sea un administrador de confianza. Esto es particularmente relevante para los recursos de Lake Formation que se comparten entre varias organizaciones y AWS cuentas. ## Responsabilidades de los administradores de EKS + El espacio de nombres `System` debe estar protegido. No se permitirá que ningún usuario, recurso, entidad o herramienta tenga permisos RBAC de Kubernetes en los recursos de Kubernetes del espacio de nombres `System`. + Ningún usuario, recurso o entidad, excepto el servicio EMR en EKS, debe tener acceso a `CREATE` acceso a POD, CONFIG\$1MAP y SECRET en el espacio de nombres `User`. + `System` controladores y `System` ejecutores contienen información confidencial. Por lo tanto, los eventos de Spark, los registros de los controladores de Spark y los registros de los ejecutores de Spark del espacio de nombres `System` no deberían reenviarse a sistemas de almacenamiento de registros externos. # Resolución de problemas ## Registro EMR en EKS utiliza los perfiles de recursos de Spark para dividir la ejecución de los trabajos. Amazon EMR en EKS utiliza el perfil de usuario para ejecutar el código que proporcionó, mientras que el perfil del sistema implementa las políticas de Lake Formation. Puede acceder a los registros de los contenedores ejecutados como perfil de usuario configurando la StartJobRun solicitud con [MonitoringConfiguration](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-s3.html). ## Servidor de historial de Spark El servidor de historial de Spark contienen todos los eventos de Spark generados a partir del perfil de usuario, así como los eventos confidenciales generados a partir del controlador del sistema. Puede ver todos los contenedores tanto del usuario como de los controladores del sistema en la pestaña **Ejecutores**. Sin embargo, los enlaces de registro solo están disponibles para el perfil de usuario. ## Error de trabajo: permisos de Lake Formation insuficientes Asegúrese de que su rol de ejecución de trabajos tenga los permisos para ejecutar `SELECT` y `DESCRIBE` en la tabla a la que está accediendo. ## Error de trabajo en la ejecución de RDD Actualmente, EMR en EKS no admite operaciones de conjuntos de datos distribuidos resilientes (RDD) en trabajos habilitados para Lake Formation. ## Imposible acceder a archivos de datos en Amazon S3 Asegúrese de haber registrado la ubicación del lago de datos en Lake Formation. ## Excepción de validación de seguridad EMR en EKS detectó un error de validación de seguridad. Ponte en contacto con AWS el servicio de asistencia para obtener ayuda ## Compartir el catálogo de datos y las tablas de AWS Glue entre cuentas Puede compartir bases de datos y tablas entre cuentas y seguir utilizando Lake Formation. Para obtener más información, consulte [Intercambio de datos entre cuentas en Lake Formation](https://docs.aws.amazon.com/lake-formation/latest/dg/cross-account-permissions.html) y [¿Cómo comparto el catálogo de datos y las tablas de AWS Glue entre cuentas mediante AWS Lake](https://repost.aws/knowledge-center/glue-lake-formation-cross-account) Formation? . ## Iceberg Job lanza un error de inicialización que no configura la región AWS El mensaje es el siguiente: ``` 25/02/25 13:33:19 ERROR SparkFGACExceptionSanitizer: Client received error with id = b921f9e6-f655-491f-b8bd-b2842cdc20c7, reason = IllegalArgumentException, message = Cannot initialize LakeFormationAwsClientFactory, please set client.region to a valid aws region ``` Asegúrese de que la configuración de Spark `spark.sql.catalog.catalog_name.client.region` esté establecida en una región válida. ## Lanzamiento de Iceberg Job SparkUnsupportedOperationException El mensaje es el siguiente: ``` 25/02/25 13:53:15 ERROR SparkFGACExceptionSanitizer: Client received error with id = 921fef42-0800-448b-bef5-d283d1278ce0, reason = SparkUnsupportedOperationException, message = Either glue.id or glue.account-id is set with non-default account. Cross account access with fine-grained access control is only supported with AWS Resource Access Manager. ``` Asegúrese de que la configuración de Spark `spark.sql.catalog.catalog_name.glue.account-id` esté establecida en un ID de cuenta válido. ## El trabajo Iceberg falla con el mensaje “403 Acceso denegado” durante la operación MERGE El mensaje es el siguiente: ``` software.amazon.awssdk.services.s3.model.S3Exception: Access Denied (Service: S3, Status Code: 403, ... at software.amazon.awssdk.services.s3.DefaultS3Client.deleteObject(DefaultS3Client.java:3365) at org.apache.iceberg.aws.s3.S3FileIO.deleteFile(S3FileIO.java:162) at org.apache.iceberg.io.FileIO.deleteFile(FileIO.java:86) at org.apache.iceberg.io.RollingFileWriter.closeCurrentWriter(RollingFileWriter.java:129) ``` Inhabilite las operaciones de eliminación de S3 en Spark añadiendo la siguiente propiedad. `--conf spark.sql.catalog.s3-table-name.s3.delete-enabled=false`.