Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Verwendung von Amazon EMR auf EKS mit AWS Lake Formation für eine detaillierte Zugriffskontrolle Mit Amazon EMR Version 7.7 und höher können Sie AWS Lake Formation nutzen, um detaillierte Zugriffskontrollen auf AWS Glue Data Catalog-Tabellen anzuwenden, die von Amazon S3 S3-Buckets unterstützt werden. Mit dieser Funktion können Sie Zugriffskontrollen auf Tabellen-, Zeilen-, Spalten- und Zellenebene für Leseabfragen in Ihrem Amazon EMR on EKS Spark-Jobs konfigurieren. **Topics** + [ # So funktioniert Amazon EMR auf EKS mit AWS Lake Formation ](security_iam_fgac-lf-works.md) + [ # Aktivieren Sie Lake Formation mit Amazon EMR auf EKS ](security_iam_fgac-lf-enable.md) + [ # Überlegungen und Einschränkungen ](security_iam_fgac-considerations.md) + [ # Fehlerbehebung ](security_iam_fgac-troubleshooting.md) # So funktioniert Amazon EMR auf EKS mit AWS Lake Formation Wenn Sie Amazon EMR on EKS mit Lake Formation verwenden, können Sie für jeden Spark-Job eine Berechtigungsebene erzwingen, um die Lake Formation Formation-Berechtigungssteuerung anzuwenden, wenn Amazon EMR on EKS Jobs ausführt. Amazon EMR on EKS verwendet [Spark-Ressourcenprofile, um zwei Profile](https://spark.apache.org/docs/latest/api/java/org/apache/spark/resource/ResourceProfile.html) für die effektive Ausführung von Jobs zu erstellen. Das Benutzerprofil führt vom Benutzer bereitgestellten Code aus, während das Systemprofil die Lake Formation-Richtlinien durchsetzt. Jeder Lake Formation Formation-fähige Job verwendet zwei Spark-Treiber, einen für das Benutzerprofil und einen weiteren für das Systemprofil. Weitere Informationen finden Sie unter Was ist [AWS Lake Formation](https://docs.aws.amazon.com/lake-formation/latest/dg/what-is-lake-formation.html). Im Folgenden finden Sie einen allgemeinen Überblick darüber, wie Amazon EMR auf EKS Zugriff auf Daten erhält, die durch Sicherheitsrichtlinien von Lake Formation geschützt sind. ![\[Arbeitsplatzsicherheit durch Lake Formation\]](http://docs.aws.amazon.com/de_de/emr/latest/EMR-on-EKS-DevelopmentGuide/images/fgac_diagram_eks_spark.png) Die folgenden Schritte beschreiben diesen Prozess: 1. Ein Benutzer sendet einen Spark-Job an einen AWS Lake Formation-fähigen Amazon EMR auf einem virtuellen EKS-Cluster. 1. Der Service Amazon EMR on EKS richtet den Benutzertreiber ein und führt den Job im Benutzerprofil aus. Der Benutzertreiber führt eine schlanke Version von Spark aus, die nicht in der Lage ist, Aufgaben zu starten, Executors anzufordern, auf Amazon S3 oder den Glue-Datenkatalog zuzugreifen. Es erstellt nur einen Jobplan. 1. Der Service Amazon EMR on EKS richtet einen zweiten Treiber ein, der als Systemtreiber bezeichnet wird, und führt ihn im Systemprofil (mit einer privilegierten Identität) aus. Amazon EKS richtet einen verschlüsselten TLS-Kanal zwischen den beiden Treibern für die Kommunikation ein. Der Benutzertreiber verwendet den Kanal, um die Jobpläne an den Systemtreiber zu senden. Der Systemtreiber führt keinen vom Benutzer übermittelten Code aus. Es läuft in vollem Umfang mit Spark und kommuniziert mit Amazon S3 und dem Datenkatalog für den Datenzugriff. Es fordert Ausführende an und stellt den Jobplan in eine Abfolge von Ausführungsphasen zusammen. 1. Der Service Amazon EMR on EKS führt dann die Phasen auf Executors aus. Der Benutzercode wird in jeder Phase ausschließlich auf Benutzerprofil-Executoren ausgeführt. 1. Stufen, die Daten aus Datenkatalogtabellen lesen, die durch Lake Formation geschützt sind, oder solche, die Sicherheitsfilter anwenden, werden an Systemausführende delegiert. # Aktivieren Sie Lake Formation mit Amazon EMR auf EKS Mit Amazon EMR Version 7.7 und höher können Sie AWS Lake Formation nutzen, um detaillierte Zugriffskontrollen auf Datenkatalogtabellen anzuwenden, die von Amazon S3 unterstützt werden. Mit dieser Funktion können Sie Zugriffskontrollen auf Tabellen-, Zeilen-, Spalten- und Zellenebene für Leseabfragen in Ihrem Amazon EMR on EKS Spark-Jobs konfigurieren. In diesem Abschnitt wird beschrieben, wie Sie eine Sicherheitskonfiguration erstellen und Lake Formation für die Verwendung mit Amazon EMR einrichten. Außerdem wird beschrieben, wie Sie einen virtuellen Cluster mit der Sicherheitskonfiguration erstellen, die Sie für Lake Formation erstellt haben. Diese Abschnitte sollen nacheinander abgeschlossen werden. ## Schritt 1: Auf Lake Formation basierende Berechtigungen auf Spalten-, Zeilen- oder Zellenebene einrichten Um Berechtigungen auf Zeilen- und Spaltenebene mit Lake Formation anzuwenden, muss der Data Lake-Administrator für Lake Formation zunächst das **LakeFormationAuthorizedCaller**Sitzungs-Tag festlegen. Lake Formation verwendet dieses Sitzungs-Tag, um Anrufer zu autorisieren und Zugriff auf den Data Lake zu gewähren. Navigieren Sie zur AWS Lake Formation Formation-Konsole und wählen Sie im Bereich **Administration** in der Seitenleiste die Option **Anwendungsintegrationseinstellungen** aus. Aktivieren Sie dann das Kontrollkästchen **Zulassen, dass externe Engines Daten an Amazon S3 S3-Standorten filtern, die bei Lake Formation registriert** sind. Fügen Sie das **AWS Konto** hinzu IDs , auf dem die Spark-Jobs ausgeführt werden sollen, und die **Sitzungs-Tag-Werte**. ![\[Einstellungen für die Anwendungsintegration\]](http://docs.aws.amazon.com/de_de/emr/latest/EMR-on-EKS-DevelopmentGuide/images/application_integration_settings_fgac.png) Beachten Sie, dass das hier übergebene **LakeFormationAuthorizedCaller**Sitzungs-Tag **SecurityConfiguration**später, wenn Sie IAM-Rollen einrichten, in Abschnitt 3 übergeben wird. ## Schritt 2: Richten Sie die EKS-RBAC-Berechtigungen ein Zweitens richten Sie Berechtigungen für die rollenbasierte Zugriffskontrolle ein. ### Stellen Sie EKS-Cluster-Berechtigungen für den Amazon EMR on EKS-Service bereit Der Amazon EMR on EKS Service muss über EKS-Cluster-Rollenberechtigungen verfügen, damit er namespace-übergreifende Berechtigungen für den Systemtreiber erstellen kann, um Benutzerausführungen im Benutzernamespace auszugliedern. **Cluster-Rolle erstellen** In diesem Beispiel werden Berechtigungen für eine Sammlung von Ressourcen definiert. ``` 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 ``` **Erstellen Sie Cluster-Rollenbindungen** ``` 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 ``` ### Stellen Sie Namespace-Zugriff auf den Amazon EMR on EKS-Service bereit Erstellen Sie zwei Kubernetes-Namespaces, einen für Benutzertreiber und Executors und einen weiteren für Systemtreiber und Executors, und aktivieren Sie Amazon EMR on EKS Service Access, um Jobs sowohl in Benutzer- als auch in System-Namespaces einzureichen. [Folgen Sie der vorhandenen Anleitung, um Zugriff für jeden Namespace zu gewähren. Diese finden Sie unter Clusterzugriff aktivieren mit. `aws-auth`](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-cluster-access.html#setting-up-cluster-access-aws-auth) ## Schritt 3: Richten Sie IAM-Rollen für Benutzer- und Systemprofilkomponenten ein Drittens richten Sie Rollen für bestimmte Komponenten ein. Ein Lake Formation-fähiger Spark-Job besteht aus zwei Komponenten, Benutzer und System. Der Benutzertreiber und die Executoren werden im Benutzernamespace ausgeführt und sind an den Namen gebunden, der in der API JobExecutionRole übergeben wird. StartJobRun Der Systemtreiber und die Executoren werden im System-Namespace ausgeführt und sind an die Rolle gebunden. **QueryEngine** ### Konfigurieren Sie die Query Engine-Rolle Die QueryEngine Rolle ist an die System Space-Komponenten gebunden und hätte die Berechtigung, das Tag **JobExecutionRole**with **LakeFormationAuthorizedCaller**Session anzunehmen. Die IAM-Berechtigungsrichtlinie der Query Engine-Rolle lautet wie folgt: ------ #### [ 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": [ "*" ] } ] } ``` ------ Konfigurieren Sie die Vertrauensrichtlinie der Query Engine-Rolle so, dass sie dem Kubernetes-System-Namespace vertraut. ``` aws emr-containers update-role-trust-policy \ --cluster-name eks cluster \ --namespace eks system namespace \ --role-name query_engine_iam_role_name ``` Weitere Informationen finden Sie unter [Aktualisierung der Rollenvertrauensrichtlinie](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-trust-policy.html). ### Die Rolle „Jobausführung“ konfigurieren Lake Formation Formation-Berechtigungen kontrollieren den Zugriff auf AWS Glue Data Catalog-Ressourcen, Amazon S3 S3-Standorte und die zugrunde liegenden Daten an diesen Standorten. IAM-Berechtigungen kontrollieren den Zugriff auf Lake Formation und AWS Glue APIs sowie auf Ressourcen. Obwohl Sie möglicherweise über die Lake Formation Formation-Berechtigung verfügen, auf eine Tabelle im Datenkatalog (SELECT) zuzugreifen, schlägt Ihr Vorgang fehl, wenn Sie nicht über die IAM-Berechtigung für die `glue:Get*` API-Operationen verfügen. IAM-Berechtigungsrichtlinie von **JobExecutionRole**: Die **JobExecution**Rolle sollte die Richtlinienerklärungen in ihrer Berechtigungsrichtlinie enthalten. ------ #### [ 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-Vertrauensrichtlinie für: **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" ] } ] } ``` ------ Konfigurieren Sie die Vertrauensrichtlinie der Jobausführungsrolle so, dass sie dem Kubernetes-Benutzernamespace vertraut: ``` aws emr-containers update-role-trust-policy \ --cluster-name eks cluster \ --namespace eks User namespace \ --role-name job_execution_role_name ``` Weitere Informationen finden Sie unter [Aktualisieren der Vertrauensrichtlinie der Jobausführungsrolle](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-trust-policy.html). ## Schritt 4: Sicherheitskonfiguration einrichten Um einen Lake Formation-fähigen Job auszuführen, müssen Sie eine Sicherheitskonfiguration erstellen. ``` 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" } } }' ``` Stellen Sie sicher, dass das im Feld **authorizedSessionTagValue** übergebene Session-Tag Lake Formation autorisieren kann. Stellen Sie den Wert auf den in Lake Formation konfigurierten Wert ein, in[Schritt 1: Auf Lake Formation basierende Berechtigungen auf Spalten-, Zeilen- oder Zellenebene einrichten](#security_iam_fgac-lf-enable-permissions). ## Schritt 5: Erstellen Sie einen virtuellen Cluster Erstellen Sie einen virtuellen Amazon EMR on EKS-Cluster mit einer Sicherheitskonfiguration. ``` 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 ``` Stellen Sie sicher, dass die **SecurityConfiguration**ID aus dem vorherigen Schritt übergeben wird, damit die Lake Formation Formation-Autorisierungskonfiguration auf alle Jobs angewendet wird, die auf dem virtuellen Cluster ausgeführt werden. Weitere Informationen finden Sie unter [Registrieren des Amazon EKS-Clusters bei Amazon EMR.]() ## Schritt 6: Einen Job im FGAC Enabled einreichen VirtualCluster Das Verfahren für die Einreichung von Job ist sowohl für Jobs außerhalb von Lake Formation als auch für Jobs in Lake Formation identisch. Weitere Informationen finden Sie unter [Einen Job einreichen, der mit ausgeführt wird `StartJobRun`](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-submit.html). Der Spark-Treiber, der Executor und die Ereignisprotokolle des Systemtreibers werden zum Debuggen im S3-Bucket des AWS Dienstkontos gespeichert. Wir empfehlen, im Job Run einen vom Kunden verwalteten KMS-Schlüssel zu konfigurieren, um alle im AWS Service-Bucket gespeicherten Protokolle zu verschlüsseln. Weitere Informationen zur Aktivierung der Protokollverschlüsselung finden Sie unter [Amazon EMR in EKS-Protokollen verschlüsseln](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/security_iam_fgac-logging-kms.html). # Überlegungen und Einschränkungen Beachten Sie die folgenden Überlegungen und Einschränkungen, wenn Sie Lake Formation mit Amazon EMR auf EKS verwenden: + Amazon EMR on EKS unterstützt eine differenzierte Zugriffskontrolle über Lake Formation nur für die Tabellenformate Apache Hive, Apache Iceberg, Apache Hudi und Delta. Zu den Apache Hive-Formaten gehören Parquet, ORC und xSv. + `DynamicResourceAllocation`ist standardmäßig aktiviert und kann `DynamicResourceAllocation` für Lake Formation Formation-Jobs nicht deaktiviert werden. Da der Standardwert der `spark.dynamicAllocation.maxExecutors` DRA-Konfiguration unendlich ist, konfigurieren Sie bitte einen geeigneten Wert, der Ihrer Arbeitslast entspricht. + Lake Formation-fähige Jobs unterstützen die Verwendung von benutzerdefiniertem EMR auf EKS-Images in System Driver und System Executors nicht. + Sie können Lake Formation nur mit Spark-Aufträgen verwenden. + EMR auf EKS mit Lake Formation unterstützt nur eine einzige Spark-Sitzung während eines Jobs. + EMR auf EKS mit Lake Formation unterstützt nur kontenübergreifende Tabellenabfragen, die über Ressourcenlinks gemeinsam genutzt werden. + Folgendes wird nicht unterstützt: + Resilient Distributed Datasets (RDD) + Spark-Streaming + Schreiben mit von Lake Formation erteilten Berechtigungen + Zugriffskontrolle für verschachtelte Spalten + EMR auf EKS blockiert Funktionen, die die vollständige Isolierung des Systemtreibers untergraben könnten, darunter die folgenden: + UDTs, Hive und alle benutzerdefinierten FunktionenUDFs, die benutzerdefinierte Klassen beinhalten + Benutzerdefinierte Datenquellen + Bereitstellung zusätzlicher JAR-Dateien für Spark-Erweiterungen, Konnektoren oder Metastore-Befehle `ANALYZE TABLE` + Um Zugriffskontrollen, `EXPLAIN PLAN` und DDL-Vorgänge durchzusetzen, z. B. `DESCRIBE TABLE`, sollten eingeschränkte Informationen nicht offengelegt werden. + Amazon EMR on EKS schränkt den Zugriff auf Systemtreiber-Spark-Protokolle für Lake Formation-fähige Jobs ein. Weil der Systemtreiber mit mehr Zugriffsrechten ausgeführt wird, können Ereignisse und Protokolle, die der Systemtreiber generiert, vertrauliche Informationen enthalten. Um zu verhindern, dass unbefugte Benutzer oder Code auf diese sensiblen Daten zugreifen, hat EMR auf EKS den Zugriff auf Systemtreiberprotokolle deaktiviert. Wenden Sie sich zur Fehlerbehebung an den AWS Support. + Wenn Sie einen Tabellenstandort bei Lake Formation registriert haben, durchläuft der Datenzugriffspfad die in Lake Formation gespeicherten Anmeldeinformationen, unabhängig von der IAM-Berechtigung für die Jobausführungsrolle EMR on EKS. Wenn Sie die mit dem Tabellenspeicherort registrierte Rolle falsch konfigurieren, schlagen übermittelte Jobs fehl, die die Rolle mit S3-IAM-Berechtigungen für den Tabellenspeicherort verwenden. + Beim Schreiben in eine Lake-Formation-Tabelle werden IAM-Berechtigungen und nicht die von Lake Formation erteilten Berechtigungen verwendet. Wenn Ihre Jobausführungsrolle über die erforderlichen S3-Berechtigungen verfügt, können Sie sie zum Ausführen von Schreibvorgängen verwenden. Im Folgenden werden Einschränkungen und Überlegungen bei der Verwendung von Apache Iceberg aufgeführt: + Sie können Apache Iceberg nur mit Sitzungskatalogen und nicht mit beliebig benannten Katalogen verwenden. + Iceberg-Tabellen, die in Lake Formation registriert sind, unterstützen nur die Metadatentabellen `history``metadata_log_entries`,`snapshots`,`files`,`manifests`, und`refs`. Amazon EMR blendet die Spalten aus, die möglicherweise vertrauliche Daten wie `partitions``path`, und enthalten. `summaries` Diese Einschränkung gilt nicht für Iceberg-Tabellen, die nicht in Lake Formation registriert sind. + Tabellen, die Sie nicht in Lake Formation registrieren, unterstützen alle gespeicherten Iceberg-Prozeduren. Die Prozeduren `register_table` und `migrate` werden für keine Tabellen unterstützt. + Wir empfehlen, Iceberg DataFrameWriter V2 statt V1 zu verwenden. Weitere Informationen finden Sie unter [Understanding Amazon EMR on EKS Concepts and Terminology](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-concepts.html) and [Enable Cluster Access for Amazon EMR on](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-cluster-access.html) EKS. ## Haftungsausschluss für Datenadministratoren **Anmerkung** Wenn Sie einer IAM-Rolle für EMR auf EKS Zugriff auf Lake Formation Formation-Ressourcen gewähren, müssen Sie sicherstellen, dass der EMR-Clusteradministrator oder -Operator ein vertrauenswürdiger Administrator ist. Dies ist besonders relevant für Lake Formation Formation-Ressourcen, die von mehreren Organisationen und AWS Konten gemeinsam genutzt werden. ## Verantwortlichkeiten der EKS-Administratoren + Der `System` Namespace sollte geschützt werden. Kein Benutzer, keine Ressource, keine Entität oder kein Tool darf über Kubernetes-RBAC-Berechtigungen für die Kubernetes-Ressourcen im Namespace verfügen. `System` + Kein Benutzer, keine Ressource oder Entität außer dem EMR on EKS-Dienst sollte `CREATE` Zugriff auf POD, CONFIG\$1MAP und SECRET im Namespace haben. `User` + `System`Treiber und `System` Executoren enthalten sensible Daten. Daher sollten Spark-Ereignisse, Spark-Treiberprotokolle und Spark-Executor-Protokolle im `System` Namespace nicht an externe Protokollspeichersysteme weitergeleitet werden. # Fehlerbehebung ## Protokollierung EMR auf EKS verwendet Spark-Ressourcenprofile, um die Jobausführung aufzuteilen. Amazon EMR on EKS verwendet das Benutzerprofil, um den von Ihnen bereitgestellten Code auszuführen, während das Systemprofil die Lake Formation-Richtlinien durchsetzt. Sie können auf die Protokolle der Container zugreifen, die als Benutzerprofil ausgeführt wurden, indem Sie die StartJobRun Anfrage mit konfigurieren. [MonitoringConfiguration](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-s3.html) ## Spark History Server Auf dem Spark History Server wurden alle Spark-Ereignisse aus dem Benutzerprofil generiert und alle redigierten Ereignisse wurden vom Systemtreiber generiert. Sie können alle Container sowohl der Benutzer- als auch der Systemtreiber auf der Registerkarte **Executors** sehen. Protokolllinks sind jedoch nur für das Benutzerprofil verfügbar. ## Auftrag schlägt fehl, weil die Lake-Formation-Berechtigungen unzureichend sind Stellen Sie sicher, dass Ihre Job-Ausführungsrolle über die erforderlichen Berechtigungen für die Ausführung `SELECT` und für die Tabelle verfügt, `DESCRIBE` auf die Sie zugreifen. ## Auftrag mit RDD-Ausführung ist fehlgeschlagen EMR auf EKS unterstützt derzeit keine Resilient Distributed Dataset (RDD) -Operationen für Lake Formation-fähige Jobs. ## Auf Datendateien in Amazon S3 kann nicht zugegriffen werden Stellen Sie sicher, dass Sie den Data-Lake-Standort in Lake Formation registriert haben. ## Sicherheitsvalidierungsausnahme EMR auf EKS hat einen Sicherheitsvalidierungsfehler festgestellt. Wenden Sie sich für AWS weitere Unterstützung an den Support. ## Gemeinsame Nutzung des AWS Glue-Datenkatalogs und der Tabellen für mehrere Konten Sie können Datenbanken und Tabellen für mehrere Konten freigeben und trotzdem Lake Formation verwenden. Weitere Informationen finden Sie unter [Kontoübergreifender Datenaustausch in Lake Formation](https://docs.aws.amazon.com/lake-formation/latest/dg/cross-account-permissions.html) und [Wie teile ich den AWS Glue-Datenkatalog und die Tabellen kontenübergreifend mit AWS Lake](https://repost.aws/knowledge-center/glue-lake-formation-cross-account) Formation? . ## Iceberg Job löst einen Initialisierungsfehler aus und legt die Region nicht fest AWS Die Nachricht lautet wie folgt: ``` 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 ``` Stellen Sie sicher, dass die Spark-Konfiguration auf eine gültige Region eingestellt `spark.sql.catalog.catalog_name.client.region` ist. ## Eisberg Job werfen SparkUnsupportedOperationException Die Nachricht lautet wie folgt: ``` 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. ``` Stellen Sie sicher, dass die Spark-Konfiguration auf eine gültige Konto-ID eingestellt `spark.sql.catalog.catalog_name.glue.account-id` ist. ## Iceberg-Job schlägt während des MERGE-Vorgangs mit „403 Access Denied“ fehl Die Nachricht lautet wie folgt: ``` 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) ``` Deaktivieren Sie S3-Löschvorgänge in Spark, indem Sie die folgende Eigenschaft hinzufügen. `--conf spark.sql.catalog.s3-table-name.s3.delete-enabled=false`.