Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Utilizzo di Amazon EMR su EKS con AWS Lake Formation per un controllo granulare degli accessi Con la versione 7.7 e successive di Amazon EMR, puoi sfruttare Lake AWS Formation per applicare controlli AWS di accesso dettagliati alle tabelle di Glue Data Catalog supportate da bucket Amazon S3. Questa funzionalità consente di configurare i controlli di accesso a livello di tabella, riga, colonna e cella per le query di lettura all'interno di Amazon EMR su EKS Spark Jobs. **Topics** + [Come funziona Amazon EMR su EKS con Lake Formation AWS](security_iam_fgac-lf-works.md) + [Abilita Lake Formation con Amazon EMR su EKS](security_iam_fgac-lf-enable.md) + [Considerazioni e limitazioni](security_iam_fgac-considerations.md) + [Risoluzione dei problemi](security_iam_fgac-troubleshooting.md) # Come funziona Amazon EMR su EKS con Lake Formation AWS L'utilizzo di Amazon EMR su EKS con Lake Formation ti consente di applicare un livello di autorizzazioni su ogni lavoro Spark per applicare il controllo delle autorizzazioni di Lake Formation quando Amazon EMR su EKS esegue lavori. Amazon EMR su EKS utilizza i profili di [risorse Spark per creare due profili](https://spark.apache.org/docs/latest/api/java/org/apache/spark/resource/ResourceProfile.html) per eseguire i lavori in modo efficace. Il profilo utente esegue il codice fornito dall'utente, mentre il profilo di sistema applica le politiche di Lake Formation. Ogni Job abilitato per Lake Formation utilizza due driver Spark, uno per il profilo utente e l'altro per il profilo System. Per ulteriori informazioni, vedi What is [AWS Lake Formation](https://docs.aws.amazon.com/lake-formation/latest/dg/what-is-lake-formation.html). Di seguito è riportata una panoramica di alto livello su come Amazon EMR su EKS ottiene l'accesso ai dati protetti dalle politiche di sicurezza di Lake Formation. ![\[Job security grazie a Lake Formation\]](http://docs.aws.amazon.com/it_it/emr/latest/EMR-on-EKS-DevelopmentGuide/images/fgac_diagram_eks_spark.png) I seguenti passaggi descrivono questo processo: 1. Un utente invia uno Spark Job a un cluster virtuale Amazon EMR su EKS abilitato per AWS Lake Formation. 1. Il servizio Amazon EMR on EKS configura il driver utente ed esegue il processo nel profilo utente. Lo User Driver esegue una versione snella di Spark che non è in grado di avviare attività, richiedere esecutori, accedere ad Amazon S3 o al Glue Data Catalog. Costruisce solo un Job plan. 1. Il servizio Amazon EMR on EKS configura un secondo driver chiamato System Driver e lo esegue nel profilo di sistema (con un'identità privilegiata). Amazon EKS configura un canale TLS crittografato tra i due driver per la comunicazione. Lo User Driver utilizza il canale per inviare i piani di lavoro al driver di sistema. Il driver di sistema non esegue il codice inviato dall'utente. Funziona con Spark completo e comunica con Amazon S3 e il Data Catalog per l'accesso ai dati. Richiede esecutori e compila il Job Plan in una sequenza di fasi di esecuzione. 1. Amazon EMR sul servizio EKS esegue quindi le fasi relative agli esecutori. Il codice utente in qualsiasi fase viene eseguito esclusivamente sugli esecutori dei profili utente. 1. Le fasi che leggono i dati dalle tabelle del Data Catalog protette da Lake Formation o quelle che applicano filtri di sicurezza sono delegate agli esecutori di sistema. # Abilita Lake Formation con Amazon EMR su EKS Con Amazon EMR versione 7.7 e successive, puoi sfruttare Lake AWS Formation per applicare controlli di accesso granulari alle tabelle di Data Catalog supportate da Amazon S3. Questa funzionalità consente di configurare i controlli di accesso a livello di tabella, riga, colonna e cella per le query di lettura all'interno di Amazon EMR su EKS Spark Jobs. Questa sezione spiega come creare una configurazione di sicurezza e configurare Lake Formation per l'utilizzo con Amazon EMR. Descrive inoltre come creare un cluster virtuale con la configurazione di sicurezza creata per Lake Formation. Queste sezioni devono essere completate in sequenza. ## Passaggio 1: configurare le autorizzazioni a livello di colonna, riga o cella basate su Lake Formation Innanzitutto, per applicare le autorizzazioni a livello di riga e colonna con Lake Formation, l'amministratore del data lake per Lake Formation deve impostare il tag di **LakeFormationAuthorizedCaller**sessione. Lake Formation utilizza questo tag di sessione per autorizzare i chiamanti e fornire l'accesso al data lake. Vai alla console di AWS Lake Formation e seleziona l'opzione **Impostazioni di integrazione delle applicazioni** dalla sezione **Amministrazione** nella barra laterale. Quindi, seleziona la casella **Consenti ai motori esterni di filtrare i dati nelle località Amazon S3 registrate con Lake Formation**. Aggiungi l'**AWS account IDs ** in cui verranno eseguiti gli Spark Jobs e i valori del **tag di sessione**. ![\[Impostazioni di integrazione delle applicazioni\]](http://docs.aws.amazon.com/it_it/emr/latest/EMR-on-EKS-DevelopmentGuide/images/application_integration_settings_fgac.png) Nota che il tag di **LakeFormationAuthorizedCaller**sessione passato qui viene passato in un **SecurityConfiguration**secondo momento quando configuri i ruoli IAM, nella sezione 3. ## Fase 2: Configurazione delle autorizzazioni EKS RBAC In secondo luogo, si impostano le autorizzazioni per il controllo degli accessi basato sui ruoli. ### Fornisci le autorizzazioni del cluster EKS al servizio Amazon EMR su EKS Il servizio Amazon EMR su EKS deve disporre delle autorizzazioni EKS Cluster Role in modo da poter creare autorizzazioni cross-namespace per consentire al driver di sistema di inserire gli esecutori degli utenti nello spazio dei nomi utente. **Crea un ruolo del cluster** Questo esempio definisce le autorizzazioni per una raccolta di risorse. ``` 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 ``` **Crea associazioni di ruoli del cluster** ``` 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 ``` ### Fornisci l'accesso Namespace al servizio Amazon EMR on EKS Crea due namespace Kubernetes, uno per driver utente ed esecutori e un altro per driver ed esecutori di sistema, e abilita l'accesso al servizio Amazon EMR su EKS per inviare lavori sia nei namespace utente che in quelli di sistema. [Segui la guida esistente per fornire l'accesso a ogni spazio dei nomi, disponibile in Abilita l'accesso al cluster utilizzando. `aws-auth`](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-cluster-access.html#setting-up-cluster-access-aws-auth) ## Fase 3: Configurazione dei ruoli IAM per i componenti del profilo utente e di sistema In terzo luogo, si impostano i ruoli per componenti specifici. Uno Spark Job abilitato per Lake Formation ha due componenti, utente e sistema. Il driver User e gli executor vengono eseguiti nello spazio dei nomi utente e sono legati a ciò che viene passato nell' JobExecutionRole API. StartJobRun Il driver e gli executor di sistema vengono eseguiti nello spazio dei nomi System e sono legati al ruolo. **QueryEngine** ### Configura il ruolo di Query Engine Il QueryEngine ruolo è legato ai componenti dello spazio di sistema e avrebbe le autorizzazioni per assumere il tag **JobExecutionRole**with **LakeFormationAuthorizedCaller**Session. Il ruolo IAM Permissions Policy of Query Engine è il seguente: ------ #### [ 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": [ "*" ] } ] } ``` ------ Configura la politica di attendibilità del ruolo Query Engine per considerare attendibile lo spazio dei nomi 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 ``` Per ulteriori informazioni, consulta [Aggiornamento](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-trust-policy.html) della policy di attendibilità dei ruoli. ### Configurazione del ruolo Job Execution Le autorizzazioni di Lake Formation controllano l'accesso alle risorse di AWS Glue Data Catalog, alle sedi Amazon S3 e ai dati sottostanti in tali sedi. Le autorizzazioni IAM controllano l'accesso a Lake Formation and AWS Glue APIs e alle risorse. Sebbene tu possa avere l'autorizzazione Lake Formation per accedere a una tabella nel Data Catalog (SELECT), l'operazione fallisce se non disponi dell'autorizzazione IAM sulle operazioni `glue:Get*` API. Politica sulle autorizzazioni IAM di **JobExecutionRole**: Il **JobExecution**ruolo dovrebbe avere le dichiarazioni politiche nella sua politica sulle autorizzazioni. ------ #### [ 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": [ "*" ] } ] } ``` ------ IAM Trust Policy per: **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" ] } ] } ``` ------ Configura la Trust Policy of Job execution Role per considerare attendibile lo spazio dei nomi utente Kubernetes: ``` aws emr-containers update-role-trust-policy \ --cluster-name eks cluster \ --namespace eks User namespace \ --role-name job_execution_role_name ``` Per ulteriori informazioni, consulta [Aggiornare la politica di fiducia del ruolo di esecuzione del lavoro](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-trust-policy.html). ## Fase 4: Configurazione della configurazione di sicurezza Per eseguire un job abilitato per Lake Formation, è necessario creare una configurazione di sicurezza. ``` 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" } } }' ``` Assicurati che il tag di sessione passato nel campo **authorizedSessionTagValue** possa autorizzare Lake Formation. Imposta il valore su quello configurato in Lake Formation, in[Passaggio 1: configurare le autorizzazioni a livello di colonna, riga o cella basate su Lake Formation](#security_iam_fgac-lf-enable-permissions). ## Fase 5: Creare un cluster virtuale Crea un cluster virtuale Amazon EMR su EKS con una configurazione di sicurezza. ``` 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 ``` Assicurati che venga passato l'**SecurityConfiguration**ID del passaggio precedente, in modo che la configurazione di autorizzazione di Lake Formation venga applicata a tutti i lavori in esecuzione sul cluster virtuale. Per ulteriori informazioni, consulta [Registrare il cluster Amazon EKS con Amazon EMR](). ## Fase 6: Inviare un Job in FGAC Enabled VirtualCluster Il processo di invio dei lavori è lo stesso sia per i lavori non Lake Formation che per quelli di Lake Formation. Per ulteriori informazioni, consulta [Inviare un lavoro eseguito con `StartJobRun`](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-submit.html). Il driver Spark, l'Executor e i registri degli eventi del driver di sistema sono archiviati nel bucket S3 di AWS Service Account per il debug. Consigliamo di configurare una chiave KMS gestita dal cliente nel Job Run per crittografare tutti i log archiviati nel bucket di servizi. AWS Per ulteriori informazioni sull'attivazione della crittografia dei log, [consulta Encrypting Amazon EMR sui](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/security_iam_fgac-logging-kms.html) log EKS. # Considerazioni e limitazioni Tieni presente le seguenti considerazioni e limitazioni quando utilizzi Lake Formation con Amazon EMR su EKS: + Amazon EMR su EKS supporta il controllo granulare degli accessi tramite Lake Formation solo per i formati di tabella Apache Hive, Apache Iceberg, Apache Hudi e Delta. I formati Apache Hive includono Parquet, ORC e XSv. + `DynamicResourceAllocation`è abilitato per impostazione predefinita e non è possibile disattivarlo `DynamicResourceAllocation` per i lavori di Lake Formation. Poiché il valore predefinito della `spark.dynamicAllocation.maxExecutors` configurazione DRA è infinito, configurate un valore appropriato in base al carico di lavoro. + I job abilitati per Lake Formation non supportano l'utilizzo di EMR personalizzato su immagini EKS in System Driver e System Executors. + Si può usare Lake Formation solo con i processi Spark. + EMR su EKS with Lake Formation supporta solo una singola sessione Spark per tutta la durata di un job. + EMR su EKS with Lake Formation supporta solo le query tabellari tra account condivise tramite link alle risorse. + I seguenti elementi non sono supportati: + Resilient Distributed Dataset (RDD) + Streaming di Spark + Scrivere con le autorizzazioni concesse da Lake Formation + Controllo degli accessi per colonne annidate + L'EMR su EKS blocca le funzionalità che potrebbero compromettere il completo isolamento dei driver di sistema, tra cui: + UDTs, Hive UDFs e qualsiasi funzione definita dall'utente che coinvolga classi personalizzate + Origini dati personalizzate + Fornitura di jar aggiuntivi per l'estensione Spark, il connettore o il comando metastore `ANALYZE TABLE` + Per applicare i controlli di accesso, `EXPLAIN PLAN` e le operazioni DDL, come `DESCRIBE TABLE` non espongono informazioni riservate. + Amazon EMR su EKS limita l'accesso ai log Spark dei driver di sistema sui job abilitati per Lake Formation. Poiché il driver di sistema viene eseguito con più accessi, gli eventi e i log generati da quest'ultimo possono includere informazioni riservate. Per impedire a utenti o codici non autorizzati di accedere a questi dati sensibili, EMR su EKS ha disabilitato l'accesso ai registri dei driver di sistema. Per la risoluzione dei problemi, contatta l'assistenza. AWS + Se hai registrato una posizione in una tabella con Lake Formation, il percorso di accesso ai dati passa attraverso le credenziali archiviate di Lake Formation, indipendentemente dall'autorizzazione IAM per il ruolo di esecuzione del lavoro EMR on EKS. Se configuri erroneamente il ruolo registrato con la posizione della tabella, i lavori inviati che utilizzano il ruolo con l'autorizzazione S3 IAM per la posizione della tabella avranno esito negativo. + La scrittura su una tabella Lake Formation utilizza l'autorizzazione IAM anziché le autorizzazioni concesse da Lake Formation. Se il tuo ruolo di esecuzione del lavoro dispone delle autorizzazioni S3 necessarie, puoi utilizzarlo per eseguire operazioni di scrittura. Di seguito sono riportate considerazioni e limitazioni per l'utilizzo di Apache Iceberg: + È possibile utilizzare Apache Iceberg solo con il catalogo delle sessioni e non con i cataloghi con nomi arbitrari. + Le tabelle Iceberg registrate in Lake Formation supportano solo le tabelle di metadati`history`,`metadata_log_entries`,, `snapshots` `files``manifests`, e. `refs` Amazon EMR nasconde le colonne che potrebbero contenere dati sensibili, ad esempio`partitions`, `path` e. `summaries` Questa limitazione non si applica alle tabelle Iceberg che non sono registrate in Lake Formation. + Le tabelle non registrate in Lake Formation supportano tutte le stored procedure di Iceberg. Le procedure di `register_table` e `migrate` non sono supportate per nessuna tabella. + Ti consigliamo di utilizzare Iceberg DataFrameWriter V2 anziché V1. Per ulteriori informazioni, consulta [Comprendere i concetti e la terminologia di Amazon EMR su EKS e](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-concepts.html) [Abilitare l'accesso ai cluster per Amazon EMR](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-cluster-access.html) su EKS. ## Dichiarazione di non responsabilità per gli amministratori di dati **Nota** Quando concedi l'accesso alle risorse di Lake Formation a un ruolo IAM per EMR su EKS, devi assicurarti che l'amministratore o l'operatore del cluster EMR sia un amministratore affidabile. Ciò è particolarmente importante per le risorse di Lake Formation condivise tra più organizzazioni e AWS account. ## Responsabilità degli amministratori EKS + Il `System` namespace deve essere protetto. A nessun utente, risorsa o entità o strumento sarebbe consentito disporre di autorizzazioni RBAC Kubernetes sulle risorse Kubernetes nel namespace. `System` + Nessun utente, risorsa o entità tranne il servizio EMR su EKS dovrebbe avere `CREATE` accesso a POD, CONFIG\$1MAP e SECRET nello spazio dei nomi. `User` + `System`i driver e `System` gli esecutori contengono dati sensibili. Pertanto, gli eventi Spark, i registri dei driver Spark e i registri degli esecutori Spark presenti nel `System` namespace non devono essere inoltrati a sistemi di archiviazione dei log esterni. # Risoluzione dei problemi ## Registrazione dei log EMR su EKS utilizza i profili di risorse Spark per suddividere l'esecuzione del lavoro. Amazon EMR su EKS utilizza il profilo utente per eseguire il codice fornito, mentre il profilo di sistema applica le politiche di Lake Formation. Puoi accedere ai log dei contenitori eseguiti come profilo utente configurando la richiesta con. StartJobRun [MonitoringConfiguration](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-s3.html) ## Spark History Server Lo Spark History Server contiene tutti gli eventi Spark generati dal profilo utente e gli eventi oscurati generati dal driver di sistema. **Puoi vedere tutti i contenitori dei driver utente e di sistema nella scheda Executors.** Tuttavia, i link di registro sono disponibili solo per il profilo utente. ## Il processo ha avuto esito negativo con autorizzazioni Lake Formation insufficienti Assicurati che il tuo ruolo di esecuzione del lavoro disponga delle autorizzazioni necessarie per l'esecuzione `SELECT` e sia presente `DESCRIBE` sulla tabella a cui stai accedendo. ## Processo con esecuzione RDD non riuscita EMR su EKS attualmente non supporta le operazioni di set di dati distribuiti resilienti (RDD) sui lavori abilitati a Lake Formation. ## Impossibile accedere ai file di dati in Amazon S3 Assicurarsi di aver registrato la posizione del data lake in Lake Formation. ## Eccezione di convalida della sicurezza EMR su EKS ha rilevato un errore di convalida della sicurezza. Contatta l' AWS assistenza per ricevere assistenza. ## Condivisione del catalogo dati e delle tabelle di AWS Glue tra account È possibile condividere database e tabelle tra account e continuare a utilizzare Lake Formation. Per ulteriori informazioni, consulta [Condivisione dei dati tra account in Lake Formation](https://docs.aws.amazon.com/lake-formation/latest/dg/cross-account-permissions.html) e [Come posso condividere AWS Glue Data Catalog e tabelle tra account utilizzando AWS Lake](https://repost.aws/knowledge-center/glue-lake-formation-cross-account) Formation? . ## Errore di inizializzazione generato da Iceberg Job che non imposta la regione AWS Il messaggio è il seguente: ``` 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 ``` Assicurati che la configurazione di Spark `spark.sql.catalog.catalog_name.client.region` sia impostata su una regione valida. ## Iceberg Job - Lancio SparkUnsupportedOperationException Il messaggio è il seguente: ``` 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. ``` Assicurati che la configurazione Spark `spark.sql.catalog.catalog_name.glue.account-id` sia impostata su un ID account valido. ## Iceberg Job fallisce con «403 Access Denied» durante l'operazione MERGE Il messaggio è il seguente: ``` 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) ``` Disabilita le operazioni di eliminazione di S3 in Spark aggiungendo la seguente proprietà. `--conf spark.sql.catalog.s3-table-name.s3.delete-enabled=false`.