Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Utilisation d'Amazon EMR sur EKS avec AWS Lake Formation pour un contrôle d'accès précis Avec les versions 7.7 et supérieures d'Amazon EMR, vous pouvez tirer parti de AWS Lake Formation pour appliquer des contrôles d'accès précis aux tables AWS Glue Data Catalog qui sont soutenues par des compartiments Amazon S3. Cette fonctionnalité vous permet de configurer des contrôles d'accès au niveau des tables, des lignes, des colonnes et des cellules pour les requêtes de lecture dans votre Amazon EMR sur EKS Spark Jobs. **Topics** + [ # Comment Amazon EMR sur EKS fonctionne avec Lake Formation AWS ](security_iam_fgac-lf-works.md) + [ # Activez la formation de Lake avec Amazon EMR sur EKS ](security_iam_fgac-lf-enable.md) + [ # Considérations et restrictions ](security_iam_fgac-considerations.md) + [ # Résolution des problèmes ](security_iam_fgac-troubleshooting.md) # Comment Amazon EMR sur EKS fonctionne avec Lake Formation AWS L'utilisation d'Amazon EMR sur EKS avec Lake Formation vous permet d'appliquer une couche d'autorisations à chaque tâche Spark afin d'appliquer le contrôle des autorisations de Lake Formation lorsqu'Amazon EMR sur EKS exécute des tâches. Amazon EMR sur EKS utilise les [profils de ressources Spark](https://spark.apache.org/docs/latest/api/java/org/apache/spark/resource/ResourceProfile.html) pour créer deux profils afin d'exécuter efficacement les tâches. Le profil utilisateur exécute le code fourni par l'utilisateur, tandis que le profil système applique les politiques de Lake Formation. Chaque Job activé par Lake Formation utilise deux pilotes Spark, l'un pour le profil utilisateur et l'autre pour le profil système. Pour plus d'informations, voir Qu'est-ce que [AWS Lake Formation](https://docs.aws.amazon.com/lake-formation/latest/dg/what-is-lake-formation.html) ? Vous trouverez ci-dessous une présentation détaillée de la manière dont Amazon EMR on EKS accède aux données protégées par les politiques de sécurité de Lake Formation. ![\[La sécurité de l'emploi grâce à Lake Formation\]](http://docs.aws.amazon.com/fr_fr/emr/latest/EMR-on-EKS-DevelopmentGuide/images/fgac_diagram_eks_spark.png) Les étapes suivantes décrivent ce processus : 1. Un utilisateur soumet un Spark Job à un cluster AWS virtuel Amazon EMR on EKS compatible avec Lake Formation. 1. Le service Amazon EMR on EKS configure le pilote utilisateur et exécute la tâche dans le profil utilisateur. Le pilote utilisateur exécute une version allégée de Spark qui n'est pas en mesure de lancer des tâches, des exécuteurs de requêtes, d'accéder à Amazon S3 ou au catalogue de données Glue. Il ne fait que créer un plan Job. 1. Le service Amazon EMR on EKS configure un deuxième pilote appelé pilote système et l'exécute dans le profil système (avec une identité privilégiée). Amazon EKS configure un canal TLS crypté entre les deux pilotes pour la communication. Le pilote utilisateur utilise le canal pour envoyer les plans de travail au pilote système. Le pilote système n'exécute pas le code envoyé par l'utilisateur. Il exécute Spark dans son intégralité et communique avec Amazon S3 et le catalogue de données pour accéder aux données. Il demande des exécuteurs et compile le Job Plan en une séquence d'étapes d'exécution. 1. Le service Amazon EMR on EKS exécute ensuite les étapes sur les exécuteurs. À n'importe quel stade, le code utilisateur est exécuté exclusivement sur les exécuteurs de profil utilisateur. 1. Les étapes qui lisent les données des tables du catalogue de données protégées par Lake Formation ou celles qui appliquent des filtres de sécurité sont déléguées aux exécuteurs du système. # Activez la formation de Lake avec Amazon EMR sur EKS Avec les versions 7.7 et supérieures d'Amazon EMR, vous pouvez tirer parti de AWS Lake Formation pour appliquer des contrôles d'accès précis aux tables du catalogue de données soutenues par Amazon S3. Cette fonctionnalité vous permet de configurer les contrôles d'accès au niveau des tables, des lignes, des colonnes et des cellules pour les requêtes de lecture dans votre Amazon EMR sur EKS Spark Jobs. Cette section explique comment créer une configuration de sécurité et configurer Lake Formation pour qu'il fonctionne avec Amazon EMR. Il décrit également comment créer un cluster virtuel avec la configuration de sécurité que vous avez créée pour Lake Formation. Ces sections sont destinées à être complétées dans l'ordre. ## Étape 1 : configurer les autorisations au niveau des colonnes, des lignes ou des cellules basées sur Lake Formation Tout d'abord, pour appliquer des autorisations au niveau des lignes et des colonnes à Lake Formation, l'administrateur du lac de données de Lake Formation doit définir le tag de **LakeFormationAuthorizedCaller**session. Lake Formation utilise cette balise de session pour autoriser les appelants et fournir l'accès au lac de données. Accédez à la console AWS Lake Formation et sélectionnez l'option **Paramètres d'intégration de l'application** dans la section **Administration** de la barre latérale. Cochez ensuite la case **Autoriser les moteurs externes à filtrer les données dans les sites Amazon S3 enregistrés auprès de Lake Formation**. Ajoutez le **AWS compte sur IDs ** lequel les tâches Spark seront exécutées et les **valeurs des balises de session**. ![\[Paramètres d'intégration des applications\]](http://docs.aws.amazon.com/fr_fr/emr/latest/EMR-on-EKS-DevelopmentGuide/images/application_integration_settings_fgac.png) Notez que le tag de **LakeFormationAuthorizedCaller**session transmis ici est transmis **SecurityConfiguration**ultérieurement lorsque vous configurez les rôles IAM, dans la section 3. ## Étape 2 : Configuration des autorisations EKS RBAC Ensuite, vous configurez des autorisations pour le contrôle d'accès basé sur les rôles. ### Fournir des autorisations de cluster EKS au service Amazon EMR on EKS Le service Amazon EMR on EKS doit disposer d'autorisations de rôle de cluster EKS afin de pouvoir créer des autorisations d'espaces de noms multiples permettant au pilote système de créer des exécuteurs utilisateur dans l'espace de noms utilisateur. **Créer un rôle de cluster** Cet exemple définit les autorisations pour un ensemble de ressources. ``` 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 ``` **Création de liaisons de rôles de 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 ``` ### Fournir un accès à l'espace de noms au service Amazon EMR on EKS Créez deux espaces de noms Kubernetes, l'un pour le pilote utilisateur et les exécuteurs, l'autre pour le pilote et les exécuteurs système, et activez l'accès au service Amazon EMR on EKS pour soumettre des tâches dans les espaces de noms utilisateur et système. Suivez le guide existant pour fournir un accès à chaque espace de noms, disponible sur [Activer l'accès au cluster à l'aide `aws-auth`](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-cluster-access.html#setting-up-cluster-access-aws-auth) de. ## Étape 3 : Configuration des rôles IAM pour les composants du profil utilisateur et du profil système Troisièmement, vous définissez des rôles pour des composants spécifiques. Un Spark Job compatible avec Lake Formation comporte deux composants, l'utilisateur et le système. Le pilote utilisateur et les exécuteurs s'exécutent dans l'espace de noms utilisateur et sont liés à JobExecutionRole celui transmis dans l' StartJobRun API. Le pilote système et les exécuteurs s'exécutent dans l'espace de noms System et sont liés au **QueryEngine**rôle. ### Configurer le rôle du moteur de requête Le QueryEngine rôle est lié aux composants de l'espace système et serait autorisé à assumer le tag **JobExecutionRole**with **LakeFormationAuthorizedCaller**Session. La politique d'autorisations IAM du rôle Query Engine est la suivante : ------ #### [ 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": [ "*" ] } ] } ``` ------ Configurez la politique de confiance du rôle Query Engine pour faire confiance à l'espace de noms Kubernetes System. ``` aws emr-containers update-role-trust-policy \ --cluster-name eks cluster \ --namespace eks system namespace \ --role-name query_engine_iam_role_name ``` Pour plus d'informations, consultez la section [Mise à jour de la politique d'approbation des rôles](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-trust-policy.html). ### Configuration du rôle d'exécution du Job Les autorisations de Lake Formation contrôlent l'accès aux ressources du catalogue de données AWS Glue, aux sites Amazon S3 et aux données sous-jacentes de ces sites. Les autorisations IAM contrôlent l'accès à la Lake Formation and AWS Glue APIs et aux ressources. Bien que vous ayez l'autorisation Lake Formation d'accéder à une table du catalogue de données (SELECT), votre opération échoue si vous ne disposez pas de l'autorisation IAM pour les opérations d'`glue:Get*`API. Politique d'autorisations IAM de **JobExecutionRole**: le **JobExecution**rôle doit avoir les déclarations de politique dans sa politique d'autorisations. ------ #### [ 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": [ "*" ] } ] } ``` ------ Politique de confiance IAM pour **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" ] } ] } ``` ------ Configurez la politique de confiance du rôle d'exécution de Job pour faire confiance à l'espace de noms utilisateur Kubernetes : ``` aws emr-containers update-role-trust-policy \ --cluster-name eks cluster \ --namespace eks User namespace \ --role-name job_execution_role_name ``` Pour plus d'informations, voir [Mettre à jour la politique de confiance du rôle d'exécution des tâches](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-trust-policy.html). ## Étape 4 : Configuration de la configuration de sécurité Pour exécuter une tâche compatible avec Lake Formation, vous devez créer une configuration de sécurité. ``` 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" } } }' ``` Assurez-vous que le tag de session transmis dans le champ **authorizedSessionTagValue** peut autoriser Lake Formation. Définissez la valeur sur celle configurée dans Lake Formation, dans[Étape 1 : configurer les autorisations au niveau des colonnes, des lignes ou des cellules basées sur Lake Formation](#security_iam_fgac-lf-enable-permissions). ## Étape 5 : Création d'un cluster virtuel Créez un cluster virtuel Amazon EMR sur EKS avec une configuration de sécurité. ``` 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 ``` Assurez-vous que l'**SecurityConfiguration**identifiant de l'étape précédente est transmis, afin que la configuration d'autorisation de Lake Formation soit appliquée à tous les jobs exécutés sur le cluster virtuel. Pour plus d'informations, consultez [Enregistrer le cluster Amazon EKS auprès d'Amazon EMR](). ## Étape 6 : Soumettre un job dans le FGAC activé VirtualCluster Le processus de soumission des offres d'emploi est le même pour les tâches autres que celles liées à Lake Formation et à Lake Formation. Pour plus d'informations, voir [Soumettre une tâche exécutée avec `StartJobRun`](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-submit.html). Le pilote Spark, l'exécuteur et les journaux d'événements du pilote système sont stockés dans le compartiment S3 du compte de AWS service à des fins de débogage. Nous recommandons de configurer une clé KMS gérée par le client dans le Job Run pour chiffrer tous les journaux stockés dans le AWS service bucket. Pour plus d'informations sur l'activation du chiffrement des journaux, consultez la section [Chiffrement d'Amazon EMR sur](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/security_iam_fgac-logging-kms.html) les journaux EKS. # Considérations et restrictions Tenez compte des considérations et limitations suivantes lorsque vous utilisez Lake Formation avec Amazon EMR sur EKS : + Amazon EMR on EKS prend en charge un contrôle d'accès précis via Lake Formation uniquement pour les formats de table Apache Hive, Apache Iceberg, Apache Hudi et Delta. Les formats Apache Hive incluent Parquet, ORC et XSv. + `DynamicResourceAllocation`est activé par défaut et vous ne pouvez pas le désactiver `DynamicResourceAllocation` pour les tâches de Lake Formation. La valeur par défaut de la `spark.dynamicAllocation.maxExecutors` configuration DRA étant infinie, veuillez configurer une valeur appropriée en fonction de votre charge de travail. + Les tâches compatibles avec Lake Formation ne prennent pas en charge l'utilisation d'EMR personnalisé sur les images EKS dans le pilote système et les exécuteurs système. + Vous ne pouvez utiliser Lake Formation qu’avec des tâches Spark. + EMR sur EKS with Lake Formation ne prend en charge qu'une seule session Spark pendant toute la durée d'une tâche. + EMR sur EKS with Lake Formation ne prend en charge que les requêtes de table entre comptes partagées via des liens de ressources. + Les éléments suivants ne sont pas pris en charge : + Jeux de données distribués résilients (RDD) + Spark Streaming + Écriture avec les autorisations accordées par Lake Formation + Contrôle d’accès pour les colonnes imbriquées + L'EMR sur EKS bloque les fonctionnalités susceptibles de compromettre l'isolation complète du pilote système, notamment les suivantes : + UDTs, Hive UDFs et toute fonction définie par l'utilisateur impliquant des classes personnalisées + Sources de données personnalisées + Fourniture de fichiers JAR supplémentaires pour l'extension Spark, le connecteur ou la commande Metastore `ANALYZE TABLE` + Pour appliquer les contrôles d’accès, les opérations `EXPLAIN PLAN` et DDL telles que `DESCRIBE TABLE` n’exposent pas les informations restreintes. + Amazon EMR on EKS restreint l'accès aux journaux Spark du pilote système pour les tâches compatibles avec Lake Formation. Étant donné que le pilote système s’exécute avec plus d’accès, les événements et les journaux générés par le pilote système peuvent inclure des informations sensibles. Pour empêcher les utilisateurs ou le code non autorisés d'accéder à ces données sensibles, EMR on EKS a désactivé l'accès aux journaux des pilotes du système. Pour le dépannage, contactez AWS le support. + Si vous avez enregistré l'emplacement d'une table auprès de Lake Formation, le chemin d'accès aux données passe par les informations d'identification stockées dans Lake Formation, indépendamment de l'autorisation IAM pour le rôle d'exécution de la tâche EMR sur EKS. Si vous configurez mal le rôle enregistré avec l'emplacement de la table, les tâches soumises qui utilisent le rôle avec l'autorisation S3 IAM sur l'emplacement de la table échoueront. + L’écriture dans une table Lake Formation utilise l’autorisation IAM plutôt que les autorisations accordées par Lake Formation. Si votre rôle d'exécution de tâches dispose des autorisations S3 nécessaires, vous pouvez l'utiliser pour exécuter des opérations d'écriture. Voici les restrictions et les considérations à prendre en compte lors de l’utilisation d’Apache Iceberg : + Vous ne pouvez utiliser Apache Iceberg qu’avec un catalogue de sessions et non avec des catalogues nommés arbitrairement. + Les tables Iceberg enregistrées dans Lake Formation ne prennent en charge que les tables de métadonnées `history``metadata_log_entries`,`snapshots`,, `files``manifests`, et`refs`. Amazon EMR masque les colonnes susceptibles de contenir des données sensibles, telles que `partitions``path`, et. `summaries` Cette restriction ne s’applique pas aux tables Iceberg qui ne sont pas enregistrées dans Lake Formation. + Les tables que vous n’enregistrez pas dans Lake Formation prennent en charge toutes les procédures stockées par Iceberg. Les procédures `register_table` et `migrate` ne sont prises en charge pour aucune table. + Nous vous recommandons d'utiliser Iceberg DataFrameWriter V2 au lieu de V1. Pour plus d'informations, consultez [Comprendre les concepts et la terminologie d'Amazon EMR on EKS et](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-concepts.html) [Activer l'accès au cluster pour Amazon EMR](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-cluster-access.html) on EKS. ## Avertissement pour les administrateurs de données **Note** Lorsque vous accordez l'accès aux ressources de Lake Formation à un rôle IAM pour EMR sur EKS, vous devez vous assurer que l'administrateur ou l'opérateur du cluster EMR est un administrateur de confiance. Cela est particulièrement pertinent pour les ressources de Lake Formation partagées entre plusieurs organisations et AWS comptes. ## Responsabilités des administrateurs d'EKS + L'`System`espace de noms doit être protégé. Aucun utilisateur, ressource, entité ou outil ne serait autorisé à disposer d'autorisations Kubernetes RBAC sur les ressources Kubernetes de l'espace de noms. `System` + Aucun utilisateur, ressource ou entité à l'exception du service EMR sur EKS ne doit avoir `CREATE` accès à POD, CONFIG\$1MAP et SECRET dans l'espace de noms. `User` + `System`les pilotes et les `System` exécuteurs contiennent des données sensibles. Ainsi, les événements Spark, les journaux des pilotes Spark et les journaux de l'exécuteur Spark présents dans l'espace de `System` noms ne doivent pas être transférés vers des systèmes de stockage de journaux externes. # Résolution des problèmes ## Logging EMR sur EKS utilise les profils de ressources Spark pour diviser l'exécution des tâches. Amazon EMR on EKS utilise le profil utilisateur pour exécuter le code que vous avez fourni, tandis que le profil système applique les politiques de Lake Formation. Vous pouvez accéder aux journaux des conteneurs exécutés en tant que profil utilisateur en configurant la StartJobRun demande avec [MonitoringConfiguration](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-s3.html). ## Serveur d'historique Spark Le serveur d'historique Spark contient tous les événements Spark générés à partir du profil utilisateur et les événements expurgés générés à partir du pilote du système. Vous pouvez voir tous les conteneurs provenant des pilotes utilisateur et système dans l'onglet **Executors**. Toutefois, les liens du journal ne sont disponibles que pour le profil utilisateur. ## Échec de la tâche en raison d’autorisations insuffisantes pour Lake Formation Assurez-vous que votre rôle d'exécution de tâches dispose des autorisations nécessaires pour s'exécuter `SELECT` et `DESCRIBE` sur la table à laquelle vous accédez. ## Échec de l’exécution de la tâche avec RDD EMR sur EKS ne prend actuellement pas en charge les opérations de jeu de données distribué résilient (RDD) sur les tâches compatibles avec Lake Formation. ## Impossible d’accéder aux fichiers de données dans Amazon S3 Assurez-vous d’avoir enregistré l’emplacement du lac de données dans Lake Formation. ## Exception de validation de sécurité EMR sur EKS a détecté une erreur de validation de sécurité. Contactez le AWS support pour obtenir de l'aide. ## Partage du catalogue de données et des tableaux AWS Glue entre les comptes Vous pouvez partager des bases de données et des tables entre les comptes tout en continuant à utiliser Lake Formation. Pour plus d'informations, voir [Partage de données entre comptes dans Lake Formation](https://docs.aws.amazon.com/lake-formation/latest/dg/cross-account-permissions.html) et [How do I share AWS Glue Data Catalog and tables cross-account using AWS Lake](https://repost.aws/knowledge-center/glue-lake-formation-cross-account) Formation ? . ## Iceberg Job lance une erreur d'initialisation et ne définit pas la région AWS Le message est le suivant : ``` 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 ``` Assurez-vous que la configuration de Spark `spark.sql.catalog.catalog_name.client.region` est définie sur une région valide. ## Iceberg Job lance SparkUnsupportedOperationException Le message est le suivant : ``` 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. ``` Assurez-vous que la configuration Spark `spark.sql.catalog.catalog_name.glue.account-id` est définie sur un identifiant de compte valide. ## Iceberg Job échoue avec « 403 accès refusé » lors de l'opération MERGE Le message est le suivant : ``` 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) ``` Désactivez les opérations S3 Delete dans Spark en ajoutant la propriété suivante. `--conf spark.sql.catalog.s3-table-name.s3.delete-enabled=false`.