

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.

# Zugreifen auf S3-Daten in einem anderen AWS Konto von EMR Serverless
<a name="jobs-s3-access"></a>

Sie können Amazon EMR Serverless-Jobs von einem AWS Konto aus ausführen und sie so konfigurieren, dass sie auf Daten in Amazon S3 S3-Buckets zugreifen, die zu einem anderen Konto gehören. AWS Auf dieser Seite wird beschrieben, wie Sie den kontenübergreifenden Zugriff auf S3 von EMR Serverless aus konfigurieren.

Jobs, die auf EMR Serverless ausgeführt werden, können eine S3-Bucket-Richtlinie oder eine angenommene Rolle verwenden, um von einem anderen AWS Konto aus auf Daten in Amazon S3 zuzugreifen.

## Voraussetzungen
<a name="jobs-s3-access-prerequisites"></a>

Um den kontoübergreifenden Zugriff für Amazon EMR Serverless einzurichten, führen Sie Aufgaben aus, während Sie bei zwei Konten angemeldet sind: AWS 
+ **`AccountA`**— Dies ist das AWS Konto, in dem Sie eine serverlose Amazon EMR-Anwendung erstellt haben. Bevor Sie den kontoübergreifenden Zugriff einrichten, sollten Sie Folgendes für dieses Konto bereithalten:
  + Eine serverlose Amazon EMR-Anwendung, in der Sie Jobs ausführen möchten.
  + Eine Rolle zur Auftragsausführung, die über die erforderlichen Berechtigungen zum Ausführen von Jobs in der Anwendung verfügt. Weitere Informationen finden Sie unter [Job-Runtime-Rollen für Amazon EMR Serverless](security-iam-runtime-role.md).
+ **`AccountB`**— Dies ist das AWS Konto, das den S3-Bucket enthält, auf den Ihre Amazon EMR Serverless-Jobs zugreifen sollen. 

## Verwenden Sie eine S3-Bucket-Richtlinie, um auf kontoübergreifende S3-Daten zuzugreifen
<a name="jobs-s3-access-how-to-s3-bucket-policy"></a>

Um auf den S3-Bucket in account B zuzugreifenaccount A, fügen Sie dem S3-Bucket in die folgende Richtlinie beiaccount B.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "ExamplePermissions1",
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-bucket-name"
      ]
    },
    {
      "Sid": "ExamplePermissions2",
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:DeleteObject"
      ],
      "Resource": [
        "arn:aws:s3:::my-bucket-name/*"
      ]
    }
  ]
}
```

------

Weitere Informationen zum kontoübergreifenden S3-Zugriff mit S3-Bucket-Richtlinien finden Sie unter [Beispiel 2: Bucket-Besitzer gewährt kontoübergreifende Bucket-Berechtigungen](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example2.html) im *Amazon Simple Storage Service-Benutzerhandbuch*.

## Verwenden Sie eine angenommene Rolle, um auf kontoübergreifende S3-Daten zuzugreifen
<a name="jobs-s3-access-how-to-assumed-role"></a>

Eine weitere Möglichkeit, den kontenübergreifenden Zugriff für Amazon EMR Serverless einzurichten, ist die `AssumeRole` Aktion von (). AWS -Security-Token-Service AWS STS AWS STS ist ein globaler Webservice, mit dem Sie temporäre Anmeldeinformationen mit eingeschränkten Rechten für Benutzer anfordern können. Mit den temporären Sicherheitsanmeldedaten, die Sie erstellen, können Sie API-Aufrufe an EMR Serverless und Amazon S3 tätigen. `AssumeRole`

Die folgenden Schritte veranschaulichen, wie Sie eine angenommene Rolle verwenden, um von EMR Serverless aus auf kontoübergreifende S3-Daten zuzugreifen: 

1. Erstellen Sie einen Amazon-S3-Bucket,*cross-account-bucket*, in `AccountB`. Weitere Informationen finden Sie unter [Erstellen eines Buckets](https://docs.aws.amazon.com/AmazonS3/latest/gsg/CreatingABucket.html) im *Amazon Simple Storage Service-Benutzerhandbuch*. Wenn Sie kontenübergreifenden Zugriff auf DynamoDB haben möchten, erstellen Sie auch eine DynamoDB-Tabelle in. `AccountB` Weitere Informationen finden Sie unter [Creating a DynamoDB table](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/getting-started-step-1.html) im *Amazon DynamoDB Developer Guide*.

1. Erstellen Sie eine `Cross-Account-Role-B` IAM-Rolle in `AccountB`, die auf das *cross-account-bucket* zugreifen kann.

   1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die IAM-Konsole unter. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)

   1. Wählen Sie **Rollen** und anschließend Neue Rolle `Cross-Account-Role-B`erstellen aus. Weitere Informationen zum Erstellen von IAM-Rollen finden Sie unter [Erstellen von IAM-Rollen im IAM-Benutzerhandbuch](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html).

   1. Erstellen Sie eine IAM-Richtlinie, die die Berechtigungen für den `Cross-Account-Role-B` Zugriff auf den *cross-account-bucket* S3-Bucket festlegt, wie die folgende Richtlinienerklärung zeigt. Fügen Sie die IAM-Richtlinie an `Cross-Account-Role-B` an. *Weitere Informationen finden Sie unter [Erstellen von IAM-Richtlinien im IAM-Benutzerhandbuch](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html).*

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": [
       {
         "Effect": "Allow",
         "Action": [
           "s3:*"
         ],
         "Resource": [
           "arn:aws:s3:::cross-account-bucket",
           "arn:aws:s3:::cross-account-bucket/*"
         ],
         "Sid": "AllowS3"
       }
     ]
   }
   ```

------

   Wenn Sie DynamoDB-Zugriff benötigen, erstellen Sie eine IAM-Richtlinie, die Berechtigungen für den Zugriff auf die kontoübergreifende DynamoDB-Tabelle festlegt. Fügen Sie die IAM-Richtlinie an `Cross-Account-Role-B` an. Weitere Informationen finden Sie unter [Amazon DynamoDB: Ermöglicht den Zugriff auf eine bestimmte Tabelle](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_dynamodb_specific-table.html) im *IAM-Benutzerhandbuch*.

   Die folgende Richtlinie ermöglicht den Zugriff auf die DynamoDB-Tabelle. `CrossAccountTable`

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": [
       {
         "Effect": "Allow",
         "Action": [
           "dynamodb:*"
         ],
         "Resource": [
           "arn:aws:dynamodb:*:123456789012:table/CrossAccountTable"
         ],
         "Sid": "AllowDYNAMODB"
       }
     ]
   }
   ```

------

1. So bearbeiten Sie die Vertrauensbeziehung für die `Cross-Account-Role-B`-Rolle.

   1. Um die Vertrauensstellung für die Rolle zu konfigurieren, wählen Sie in der IAM-Konsole die Registerkarte **Trust Relationships** für die Rolle aus`Cross-Account-Role-B`, die Sie in Schritt 2 erstellt haben.

   1. Wählen Sie **Vertrauensbeziehungen bearbeiten** aus.

   1. Fügen Sie das folgende Richtliniendokument hinzu. Dies ermöglicht es `Job-Execution-Role-A` uns`AccountA`, die `Cross-Account-Role-B` Rolle zu übernehmen.

------
#### [ JSON ]

****  

      ```
      {
        "Version":"2012-10-17",		 	 	 
        "Statement": [
          {
            "Effect": "Allow",
            "Action": [
              "sts:AssumeRole"
            ],
            "Resource": "arn:aws:iam::123456789012:role/Job-Execution-Role-A",
            "Sid": "AllowSTSAssumerole"
          }
        ]
      }
      ```

------

1. `Job-Execution-Role-A`Erteilen `AccountA` Sie die AWS STS `AssumeRole` Erlaubnis zur Übernahme`Cross-Account-Role-B`.

   1. Wählen Sie in der IAM-Konsole für das AWS Konto `AccountA` die Option aus`Job-Execution-Role-A`.

   1. Fügen Sie die folgende Richtlinienanweisung zu `Job-Execution-Role-A` hinzu, um die `AssumeRole`-Aktion in der Rolle `Cross-Account-Role-B` zu verweigern.

------
#### [ JSON ]

****  

      ```
      {
        "Version":"2012-10-17",		 	 	 
        "Statement": [
          {
            "Effect": "Allow",
            "Action": [
              "sts:AssumeRole"
            ],
            "Resource": [
              "arn:aws:iam::123456789012:role/Cross-Account-Role-B"
            ],
            "Sid": "AllowSTSAssumerole"
          }
        ]
      }
      ```

------

## Beispiele für angenommene Rollen
<a name="jobs-s3-access-how-to-assumed-role-examples"></a>

Verwenden Sie eine einzelne angenommene Rolle, um auf alle S3-Ressourcen in einem Konto zuzugreifen, oder konfigurieren Sie mit Amazon EMR 6.11 und höher mehrere IAM-Rollen, die beim Zugriff auf verschiedene kontoübergreifende S3-Buckets übernommen werden sollen.

**Topics**
+ [Greifen Sie mit einer angenommenen Rolle auf S3-Ressourcen zu](#jobs-s3-access-how-to-assumed-role-single)
+ [Greifen Sie auf S3-Ressourcen mit mehreren angenommenen Rollen zu](#jobs-s3-access-how-to-assumed-role-multiple)

### Greifen Sie mit einer angenommenen Rolle auf S3-Ressourcen zu
<a name="jobs-s3-access-how-to-assumed-role-single"></a>

**Anmerkung**  
Wenn Sie einen Job so konfigurieren, dass er eine einzelne angenommene Rolle verwendet, verwenden alle S3-Ressourcen des Jobs diese Rolle, einschließlich des `entryPoint` Skripts.

Wenn Sie eine einzige angenommene Rolle für den Zugriff auf alle S3-Ressourcen in Konto B verwenden möchten, geben Sie die folgenden Konfigurationen an:

1. Geben Sie die EMRFS-Konfiguration `fs.s3.customAWSCredentialsProvider` für an. `com.amazonaws.emr.AssumeRoleAWSCredentialsProvider`

1. Verwenden Sie für Spark `spark.emr-serverless.driverEnv.ASSUME_ROLE_CREDENTIALS_ROLE_ARN` und, `spark.executorEnv.ASSUME_ROLE_CREDENTIALS_ROLE_ARN` um die Umgebungsvariablen für Treiber und Executoren anzugeben.

1. Verwenden Sie für Hive, und `hive.emr-serverless.launch.env.ASSUME_ROLE_CREDENTIALS_ROLE_ARN``tez.am.emr-serverless.launch.env.ASSUME_ROLE_CREDENTIALS_ROLE_ARN`, `tez.task.emr-serverless.launch.env.ASSUME_ROLE_CREDENTIALS_ROLE_ARN` um die Umgebungsvariablen für den Hive-Treiber, die primäre Tez-Anwendung und die Tez-Taskcontainer anzugeben.

Die folgenden Beispiele zeigen, wie eine angenommene Rolle verwendet wird, um eine serverlose EMR-Auftragsausführung mit kontenübergreifendem Zugriff zu starten.

------
#### [ Spark ]

Das folgende Beispiel zeigt, wie eine angenommene Rolle verwendet wird, um einen EMR Serverless Spark-Job mit kontenübergreifendem Zugriff auf S3 zu starten.

```
aws emr-serverless start-job-run \
    --application-id application-id \
    --execution-role-arn job-role-arn \
    --job-driver '{
        "sparkSubmit": {
            "entryPoint": "entrypoint_location",
            "entryPointArguments": [":argument_1:", ":argument_2:"],
            "sparkSubmitParameters": "--conf spark.executor.cores=4 --conf spark.executor.memory=20g --conf spark.driver.cores=4 --conf spark.driver.memory=8g --conf spark.executor.instances=1"
        }
    }' \
     --configuration-overrides '{
        "applicationConfiguration": [{
            "classification": "spark-defaults",
            "properties": {
                "spark.hadoop.fs.s3.customAWSCredentialsProvider": "com.amazonaws.emr.AssumeRoleAWSCredentialsProvider",
                "spark.emr-serverless.driverEnv.ASSUME_ROLE_CREDENTIALS_ROLE_ARN": "arn:aws:iam::AccountB:role/Cross-Account-Role-B",
                "spark.executorEnv.ASSUME_ROLE_CREDENTIALS_ROLE_ARN": "arn:aws:iam::AccountB:role/Cross-Account-Role-B"
            }
        }]
    }'
```

------
#### [ Hive ]

Das folgende Beispiel zeigt, wie eine angenommene Rolle verwendet wird, um einen EMR Serverless Hive-Auftrag mit kontenübergreifendem Zugriff auf S3 zu starten.

```
aws emr-serverless start-job-run \
    --application-id application-id \
    --execution-role-arn job-role-arn \
    --job-driver '{
        "hive": {
            "query": "query_location",
            "parameters": "hive_parameters"
        }
    }' \
    --configuration-overrides '{
        "applicationConfiguration": [{
            "classification": "hive-site",
            "properties": {
                "fs.s3.customAWSCredentialsProvider": "com.amazonaws.emr.serverless.credentialsprovider.AssumeRoleAWSCredentialsProvider",
                "hive.emr-serverless.launch.env.ASSUME_ROLE_CREDENTIALS_ROLE_ARN": "arn:aws:iam::AccountB:role/Cross-Account-Role-B",
                "tez.am.emr-serverless.launch.env.ASSUME_ROLE_CREDENTIALS_ROLE_ARN": "arn:aws:iam::AccountB:role/Cross-Account-Role-B",
                "tez.task.emr-serverless.launch.env.ASSUME_ROLE_CREDENTIALS_ROLE_ARN": "arn:aws:iam::AccountB:role/Cross-Account-Role-B"
            }
        }]
    }'
```

------

### Greifen Sie auf S3-Ressourcen mit mehreren angenommenen Rollen zu
<a name="jobs-s3-access-how-to-assumed-role-multiple"></a>

Mit den Versionen 6.11.0 und höher von EMR Serverless können Sie mehrere IAM-Rollen konfigurieren, die beim Zugriff auf verschiedene kontoübergreifende Buckets übernommen werden sollen. Wenn Sie auf verschiedene S3-Ressourcen mit unterschiedlichen angenommenen Rollen in Konto B zugreifen möchten, verwenden Sie die folgenden Konfigurationen, wenn Sie die Jobausführung starten:

1. Geben Sie die EMRFS-Konfiguration `fs.s3.customAWSCredentialsProvider` für an. `com.amazonaws.emr.serverless.credentialsprovider.BucketLevelAssumeRoleCredentialsProvider`

1. Geben Sie die EMRFS-Konfiguration `fs.s3.bucketLevelAssumeRoleMapping` an, um die Zuordnung vom S3-Bucket-Namen zur IAM-Rolle in Konto B zu definieren, die angenommen werden soll. Der Wert sollte das Format von haben. `bucket1->role1;bucket2->role2`

Verwenden Sie zum Beispiel für `arn:aws:iam::AccountB:role/Cross-Account-Role-B-1` den Zugriff auf den Bucket `bucket1` und verwenden Sie ihn für `arn:aws:iam::AccountB:role/Cross-Account-Role-B-2` den Zugriff auf den Bucket`bucket2`. Die folgenden Beispiele zeigen, wie Sie einen serverlosen EMR-Job starten, der mit kontenübergreifendem Zugriff über mehrere angenommene Rollen ausgeführt wird.

------
#### [ Spark ]

Das folgende Beispiel zeigt, wie mehrere angenommene Rollen verwendet werden, um eine EMR Serverless Spark-Jobausführung zu erstellen.

```
aws emr-serverless start-job-run \
    --application-id application-id \
    --execution-role-arn job-role-arn \
    --job-driver '{
        "sparkSubmit": {
            "entryPoint": "entrypoint_location",
            "entryPointArguments": [":argument_1:", ":argument_2:"],
            "sparkSubmitParameters": "--conf spark.executor.cores=4 --conf spark.executor.memory=20g --conf spark.driver.cores=4 --conf spark.driver.memory=8g --conf spark.executor.instances=1"
        }
    }' \
     --configuration-overrides '{
        "applicationConfiguration": [{
            "classification": "spark-defaults",
            "properties": {
                "spark.hadoop.fs.s3.customAWSCredentialsProvider": "com.amazonaws.emr.serverless.credentialsprovider.BucketLevelAssumeRoleCredentialsProvider",
                "spark.hadoop.fs.s3.bucketLevelAssumeRoleMapping": "bucket1->arn:aws:iam::AccountB:role/Cross-Account-Role-B-1;bucket2->arn:aws:iam::AccountB:role/Cross-Account-Role-B-2"
            }
        }]
    }'
```

------
#### [ Hive ]

Die folgenden Beispiele zeigen, wie mehrere angenommene Rollen verwendet werden, um eine EMR Serverless Hive-Jobausführung zu erstellen.

```
aws emr-serverless start-job-run \
    --application-id application-id \
    --execution-role-arn job-role-arn \
    --job-driver '{
        "hive": {
            "query": "query_location",
            "parameters": "hive_parameters"
        }
    }' \
    --configuration-overrides '{
        "applicationConfiguration": [{
            "classification": "hive-site",
            "properties": {
                "fs.s3.customAWSCredentialsProvider": "com.amazonaws.emr.serverless.credentialsprovider.AssumeRoleAWSCredentialsProvider",
                "fs.s3.bucketLevelAssumeRoleMapping": "bucket1->arn:aws:iam::AccountB:role/Cross-Account-Role-B-1;bucket2->arn:aws:iam::AccountB:role/Cross-Account-Role-B-2"
            }
        }]
    }'
```

------