View a markdown version of this page

Überlegungen und Einschränkungen für Amazon EMR mit Identity-Center-Integration - Amazon EMR

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.

Überlegungen und Einschränkungen für Amazon EMR mit Identity-Center-Integration

Beachten Sie die folgenden Punkte, wenn Sie IAM Identity Center mit Amazon EMR verwenden:

  • Trusted Identity Propagation über Identity Center wird auf Amazon EMR 6.15.0 und höher und nur mit Apache Spark unterstützt. Außerdem wird die Trusted Identity Propagation über Identity Center mithilfe der Funktion EMR Runtime Roles auf Amazon EMR 7.8.0 und höher unterstützt, und zwar nur mit Apache Spark.

  • Um EMR-Cluster mit vertrauenswürdiger Identitätsweitergabe zu aktivieren, müssen Sie die verwenden, AWS CLI um eine Sicherheitskonfiguration zu erstellen, für die die Weitergabe vertrauenswürdiger Identitäten aktiviert ist, und diese Sicherheitskonfiguration verwenden, wenn Sie Ihren Cluster starten. Weitere Informationen finden Sie unter Eine Identity-Center-fähige Sicherheitskonfiguration erstellen.

  • Fine-grained Zugriffskontrollen AWS Lake Formation , die Trusted Identity Propagation verwenden, sind für Amazon EMR-Cluster in EMR-Version 7.2.0 und höher verfügbar. Zwischen den EMR-Versionen 6.15.0 und 7.1.0 ist nur Zugriffskontrolle auf Tabellenebene verfügbar, die auf Lake Formation basiert. AWS

  • Bei Amazon EMR-Clustern, die Trusted Identity Propagation verwenden, gehören zu den Vorgängen, die die Zugriffskontrolle auf der Grundlage von Lake Formation mit Apache Spark unterstützen, SELECT, ALTER TABLE, INSERT INTO und DROP TABLE.

  • Fine-grained Zugriffskontrollen AWS Lake Formation , die Trusted Identity Propagation verwenden, müssen die Lake Formation Identity Center-Konfiguration aktualisieren, indem sie die von EMR verwaltete IAM Identity-Anwendung arn als autorisiertes Ziel hinzufügen. Sie können den ARN der von Amazon EMR verwalteten IAM Identity-Anwendung finden, indem Sie die describe-security-configuration EMR-API aufrufen und nach einem Feld suchen. IdCApplicationARN Weitere Informationen finden Sie unter Aktualisierung der IAM Identity Center-Integration und erfahren Sie, wie Sie Lake Formation mit der IAM Identity Center-Konfiguration einrichten.

  • Um Fine-grained Zugriffskontrollen zu verwenden AWS Lake Formation , die Trusted Identity Propagation verwenden, sollten IAM Identity-Benutzern Lake Formation-Berechtigungen für die Standarddatenbank erteilt werden. Weitere Details: Konfigurieren Sie Lake Formation für einen IAM Identity Center-fähigen EMR-Cluster.

  • Trusted Identity Propagation mit Amazon EMR wird in den folgenden Fällen unterstützt: AWS-Regionen

    • af-south-1 – Afrika (Kapstadt)

    • ap-east-1 – Asien-Pazifik (Hongkong)

    • ap-northeast-1 – Asien-Pazifik (Tokio)

    • ap-northeast-2 – Asien-Pazifik (Seoul)

    • ap-northeast-3 – Asien-Pazifik (Osaka)

    • ap-south-1 – Asien-Pazifik (Mumbai)

    • ap-south-2— Asien-Pazifik (Hyderabad)

    • ap-southeast-1 – Asien-Pazifik (Singapur)

    • ap-southeast-2 – Asien-Pazifik (Sydney)

    • ap-southeast-3 – Asien-Pazifik (Jakarta)

    • ap-southeast-4— Asien-Pazifik (Melbourne)

    • ca-central-1 – Kanada (Zentral)

    • eu-central-1 – Europa (Frankfurt)

    • eu-central-2 – Europa (Zürich)

    • eu-north-1 – Europa (Stockholm)

    • eu-south-1 – Europa (Mailand)

    • eu-south-2— Europa (Spanien)

    • eu-west-1 – Europa (Irland)

    • eu-west-2 – Europa (London)

    • eu-west-3 – Europa (Paris)

    • il-central-1— Israel (Tel Aviv)

    • me-central-1— Naher Osten (VAE)

    • me-south-1 – Naher Osten (Bahrain)

    • sa-east-1 – Südamerika (São Paulo)

    • us-east-1 – USA Ost (Nord-Virginia)

    • us-east-2 – USA Ost (Ohio)

    • us-west-1 – USA West (Nordkalifornien)

    • us-west-2 – USA West (Oregon)

  • Wenn die Rolle „IAM-Rolle für Identity Center“ versehentlich gelöscht und neu erstellt wird, hat der Principal eine andere Principal-ID. Beispiel NewRole hätte eine Principal-ID, die nicht mit der aufgezeichneten Principal-ID 456 übereinstimmen würde. 123 Die einzige Möglichkeit, dieses Problem an dieser Stelle zu lösen, besteht darin, den Principal in den Downstream-Ressourcenrichtlinien für jedes Downstream-Konto neu festzulegen.