```
Außerdem müssen Sie Ihre Bash-Befehlsargumente maskieren, wenn Sie Befehle mit dem Script-Runner ausführen. Im Folgenden finden Sie ein Beispiel, das die Einstellung von Spark-Eigenschaften mit enthaltenen Escape-Zeichen zeigt:
```
"\"--conf spark.sql.autoBroadcastJoinThreshold=-1\n--conf spark.cradle.RSv2Mode.enabled=true\""
```
+ Laufzeit-Rollen bieten keine Unterstützung für die Steuerung des Zugriffs auf Cluster-Ressourcen wie HDFS und HMS.
+ Runtime-Rollen bieten keine Unterstützung für Docker/Container.
# Konfiguration von IAM-Servicerollen für Amazon EMR-Berechtigungen für AWS Dienste und Ressourcen
Amazon EMR und Anwendungen wie Hadoop und Spark benötigen Berechtigungen für den Zugriff auf andere AWS -Ressourcen und die Ausführung von Aktionen während der Ausführung. Jeder Cluster in Amazon EMR muss eine *Servicerolle* und eine Rolle für das Amazon-EC2-*Instance-Profil* haben. Weitere Informationen finden Sie unter [IAM-Rollen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) und [Verwenden von Instance-Profilen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html) im *IAM-Benutzerhandbuch*. Die diesen Rollen zugeordneten IAM-Richtlinien stellen dem Cluster die Berechtigung bereit, im Namen eines Benutzers mit anderen AWS -Services zu interagieren.
Eine zusätzliche Rolle, die Auto Scaling-Rolle, ist erforderlich, wenn Ihr Cluster ein Auto Scaling in Amazon EMR verwendet. Die AWS Servicerolle für EMR Notebooks ist erforderlich, wenn Sie EMR Notebooks verwenden.
Amazon EMR bietet Standardrollen und standardmäßig verwaltete Richtlinien für alle Rollen, die Berechtigungen bestimmen. Verwaltete Richtlinien werden von erstellt und verwaltet AWS, sodass sie automatisch aktualisiert werden, wenn sich die Serviceanforderungen ändern. Siehe unter [Von AWS verwaltete Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies.html) im *IAM-Benutzerhandbuch*.
Wenn Sie zum ersten Mal einen Cluster oder ein Notebook in einem Konto erstellen, existieren für Amazon EMR noch keine Rollen. Nachdem Sie sie erstellt haben, können Sie die Rollen, die ihnen zugewiesenen Richtlinien und die durch die Richtlinien erlaubten oder verweigerten Berechtigungen in der IAM-Konsole ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) anzeigen. Sie können Standardrollen für Amazon EMR zum Erstellen und Verwenden angeben, Sie können Ihre eigenen Rollen erstellen und sie einzeln angeben, wenn Sie einen Cluster erstellen, um Berechtigungen anpassen. Und Sie können Standardrollen angeben, die verwendet werden sollen, wenn Sie einen Cluster mithilfe der AWS CLI erstellen. Weitere Informationen finden Sie unter [Passen Sie IAM-Rollen mit Amazon EMR an](emr-iam-roles-custom.md).
## Ändern von identitätsbasierten Richtlinien für Berechtigungen zum Übergeben von Servicerollen für Amazon EMR
Die verwalteten Standardrichtlinien von Amazon EMR mit vollen Berechtigungen beinhalten `iam:PassRole`-Sicherheitskonfigurationen, darunter die folgenden:
+ `iam:PassRole`-Berechtigungen nur für bestimmte Amazon-EMR-Standardrollen.
+ `iam:PassedToService`Bedingungen, die es Ihnen ermöglichen, die Richtlinie nur mit bestimmten AWS Diensten zu verwenden, z. B. `elasticmapreduce.amazonaws.com` und`ec2.amazonaws.com`.
Sie können die JSON-Version der [Amazon EMRFull AccessPolicy \$1v2- und Amazon EMRService](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEMRFullAccessPolicy_v2) [Policy\$1v2-Richtlinien in der IAM-Konsole](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEMRServicePolicy_v2) anzeigen. Wir empfehlen, dass Sie neue Cluster mit den verwalteten v2-Richtlinien erstellen.
## Übersicht über Servicerollen
In der folgenden Tabelle finden Sie als Referenz die IAM-Servicerollen aufgelistet, die Amazon EMR zugeordnet sind.
| Funktion | Standardrolle | Description | Verwaltete Standardrichtlinie |
| --- | --- | --- | --- |
| [Servicerolle für Amazon EMR (EMR-Rolle)](emr-iam-role.md) | `EMR_DefaultRole_V2` | Ermöglicht Amazon EMR, in Ihrem Namen andere AWS Services aufzurufen, wenn Ressourcen bereitgestellt und Service-Level-Aktionen ausgeführt werden. Diese Rolle ist für alle Cluster erforderlich. | `AmazonEMRServicePolicy_v2` Zum Anfordern von Spot Instances ist eine serviceverknüpfte Rolle erforderlich. Wenn diese Rolle nicht vorhanden ist, benötigt die Amazon-EMR-Servicerolle die Berechtigung, sie zu erstellen, andernfalls tritt ein Berechtigungsfehler auf. Wenn Sie Spot Instances anfordern möchten, müssen Sie diese Richtlinie so aktualisieren, dass sie eine Erklärung enthält, die die Erstellung dieser serviceverknüpften Rolle ermöglicht. Weitere Informationen finden Sie unter [Servicerolle für Amazon EMR (EMR-Rolle)](emr-iam-role.md) [Service-verknüpfte Rolle für Spot-Instance-Anfragen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html#service-linked-roles-spot-instance-requests) im *Amazon EC2 EC2-Benutzerhandbuch*. |
| [Servicerolle für EC2-Cluster-Instances (EC2-Instance-Profil)](emr-iam-role-for-ec2.md) | `EMR_EC2_DefaultRole` | Anwendungsprozesse, die auf dem Hadoop-Ökosystem auf Cluster-Instances ausgeführt werden, verwenden diese Rolle, wenn sie andere Dienste aufrufen. AWS Für den Zugriff auf Daten in Amazon S3 mithilfe von EMRFS können Sie unterschiedliche Rollen angeben, die abhängig vom Speicherort der Daten in Amazon S3 angenommen werden sollen. Beispielsweise können mehrere Teams auf ein einzelnes „Datenspeicherkonto“ von Amazon S3 zugreifen. Weitere Informationen finden Sie unter [Konfigurieren von IAM-Rollen für EMRFS-Anforderungen an Amazon S3](emr-emrfs-iam-roles.md). Diese Rolle ist für alle Cluster erforderlich. | `AmazonElasticMapReduceforEC2Role`. Weitere Informationen finden Sie unter [Servicerolle für EC2-Cluster-Instances (EC2-Instance-Profil)](emr-iam-role-for-ec2.md). |
| [Servicerolle für Auto Scaling in Amazon EMR (Auto Scaling-Rolle)](emr-iam-role-automatic-scaling.md) | `EMR_AutoScaling_DefaultRole` | Ermöglicht zusätzliche Aktionen für dynamisch skalierte Umgebungen. Nur erforderlich für Cluster mit Auto Scaling in Amazon EMR. Weitere Informationen finden Sie unter [Verwenden der automatischen Skalierung mit einer benutzerdefinierten Richtlinie für Instanzgruppen in Amazon EMR](emr-automatic-scaling.md). | `AmazonElasticMapReduceforAutoScalingRole`. Weitere Informationen finden Sie unter [Servicerolle für Auto Scaling in Amazon EMR (Auto Scaling-Rolle)](emr-iam-role-automatic-scaling.md). |
| [Servicerolle für EMR Notebooks](emr-managed-notebooks-service-role.md) | `EMR_Notebooks_DefaultRole` | Stellt Berechtigungen bereit, die ein EMR-Notizbuch benötigt, um auf andere AWS Ressourcen zuzugreifen und Aktionen auszuführen. Nur erforderlich, wenn EMR-Notebooks verwendet werden. | `AmazonElasticMapReduceEditorsRole`. Weitere Informationen finden Sie unter [Servicerolle für EMR Notebooks](emr-managed-notebooks-service-role.md). `S3FullAccessPolicy` wird auch standardmäßig angehängt. Im Folgenden finden Sie den Inhalt dieser Richtlinie.. JSON
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": [
"*"
],
"Sid": "AllowS3"
}
]
}
``` |
| [Serviceverknüpfte Rolle](using-service-linked-roles.md) | `AWSServiceRoleForEMRCleanup` | Amazon EMR erstellt automatisch eine serviceverknüpfte Rolle. Wenn der Service für Amazon EMR keine Amazon EC2 Ressourcen mehr bereinigen kann, kann Amazon EMR diese Rolle zum Bereinigen verwenden. Wenn ein Cluster Spot-Instances verwendet, muss die Berechtigungsrichtlinie, die der [Servicerolle für Amazon EMR (EMR-Rolle)](emr-iam-role.md) angefügt ist, die Erstellung einer serviceverknüpften Rolle zulassen. Weitere Informationen finden Sie unter [Verwenden von serviceverknüpften Rollen für Amazon EMR](using-service-linked-roles.md). | `AmazonEMRCleanupPolicy` |
**Topics**
+ [Ändern von identitätsbasierten Richtlinien für Berechtigungen zum Übergeben von Servicerollen für Amazon EMR](#emr-iam-roles-passrole)
+ [Übersicht über Servicerollen](#emr-iam-roles-summary)
+ [Von Amazon EMR verwendete IAM-Servicerollen](emr-iam-service-roles.md)
+ [Passen Sie IAM-Rollen mit Amazon EMR an](emr-iam-roles-custom.md)
+ [Konfigurieren von IAM-Rollen für EMRFS-Anforderungen an Amazon S3](emr-emrfs-iam-roles.md)
+ [Verwenden Sie ressourcenbasierte Richtlinien für den Zugriff von Amazon EMR auf Glue Data Catalog AWS](emr-iam-roles-glue.md)
+ [Verwenden Sie IAM-Rollen mit Anwendungen, die AWS Dienste direkt aufrufen](emr-iam-roles-calling.md)
+ [Benutzern und Gruppen gestatten, Rollen zu erstellen und zu ändern](emr-iam-roles-create-permissions.md)
# Von Amazon EMR verwendete IAM-Servicerollen
Amazon EMR verwendet IAM-Servicerollen, um in Ihrem Namen Aktionen bei der Bereitstellung von Cluster-Ressourcen, der Ausführung von Anwendungen, der dynamischen Skalierung von Ressourcen und der Erstellung und Ausführung von EMR Notebooks durchzuführen. Amazon EMR verwendet in Interaktionen mit anderen AWS -Services die folgenden Rollen. Jede Rolle verfügt über eine eindeutige Funktion innerhalb von Amazon EMR. Die Themen in diesem Abschnitt beschreiben die Rollenfunktion und stellen die Standardrollen und die Berechtigungsrichtlinie für jede Rolle bereit.
Wenn Ihr Cluster über Anwendungscode verfügt, der AWS Dienste direkt aufruft, müssen Sie möglicherweise das SDK verwenden, um Rollen anzugeben. Weitere Informationen finden Sie unter [Verwenden Sie IAM-Rollen mit Anwendungen, die AWS Dienste direkt aufrufen](emr-iam-roles-calling.md).
**Topics**
+ [Servicerolle für Amazon EMR (EMR-Rolle)](emr-iam-role.md)
+ [Servicerolle für EC2-Cluster-Instances (EC2-Instance-Profil)](emr-iam-role-for-ec2.md)
+ [Servicerolle für Auto Scaling in Amazon EMR (Auto Scaling-Rolle)](emr-iam-role-automatic-scaling.md)
+ [Servicerolle für EMR Notebooks](emr-managed-notebooks-service-role.md)
+ [Verwenden von serviceverknüpften Rollen für Amazon EMR](using-service-linked-roles.md)
# Servicerolle für Amazon EMR (EMR-Rolle)
Die Amazon-EMR-Rolle definiert die zulässigen Aktionen für Amazon EMR bei der Bereitstellung von Ressourcen und der Ausführung von Service-Level-Aufgaben, die nicht im Kontext einer EC2-Instance innerhalb eines Clusters ausgeführt werden. Die Servicerolle wird beispielsweise verwendet, um EC2-Instances bereitzustellen, wenn ein Cluster gestartet wird.
+ Der Standardrollenname ist `EMR_DefaultRole_V2`.
+ Die Amazon EMR angefügte standardmäßige verwaltete Richtlinie `EMR_DefaultRole_V2` ist `AmazonEMRServicePolicy_v2`. Diese v2-Richtlinie ersetzt die veraltete verwaltete Standardrichtlinie `AmazonElasticMapReduceRole`.
`AmazonEMRServicePolicy_v2` hängt vom begrenzten Zugriff auf Ressourcen ab, die Amazon EMR bereitstellt oder nutzt. Wenn Sie diese Richtlinie verwenden, müssen Sie bei der Bereitstellung des Clusters das Benutzer-Tag `for-use-with-amazon-emr-managed-policies = true` übergeben. Amazon EMR verbreitet diese Tags automatisch. Darüber hinaus müssen Sie möglicherweise manuell ein Benutzer-Tag zu bestimmten Ressourcentypen hinzufügen, z. B. EC2-Sicherheitsgruppen, die nicht von Amazon EMR erstellt wurden. Siehe [Taggen von Ressourcen zur Verwendung verwalteter Richtlinien](emr-managed-iam-policies.md#manually-tagged-resources).
**Wichtig**
Amazon EMR verwendet diese Amazon-EMR-Servicerolle und die `AWSServiceRoleForEMRCleanup` Rolle, um Clusterressourcen in Ihrem Konto zu bereinigen, die Sie nicht mehr verwenden, z. B. Amazon-EC2-Instances. Sie müssen Aktionen für die Rollenrichtlinien angeben, um die Ressourcen zu löschen oder zu beenden. Andernfalls kann Amazon EMR diese Bereinigungsaktionen nicht durchführen, und es können Kosten für ungenutzte Ressourcen anfallen, die im Cluster verbleiben.
Im Folgenden werden die Inhalte der aktuellen `AmazonEMRServicePolicy_v2`-Richtlinie angezeigt. Sie können den aktuellen Inhalt der [https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEMRServicePolicy_v2](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEMRServicePolicy_v2) verwalteten Richtlinie auch auf der IAM-Konsole sehen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "CreateInTaggedNetwork",
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface",
"ec2:RunInstances",
"ec2:CreateFleet",
"ec2:CreateLaunchTemplate",
"ec2:CreateLaunchTemplateVersion"
],
"Resource": [
"arn:aws:ec2:*:*:subnet/*",
"arn:aws:ec2:*:*:security-group/*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/for-use-with-amazon-emr-managed-policies": "true"
}
}
},
{
"Sid": "CreateWithEMRTaggedLaunchTemplate",
"Effect": "Allow",
"Action": [
"ec2:CreateFleet",
"ec2:RunInstances",
"ec2:CreateLaunchTemplateVersion"
],
"Resource": [
"arn:aws:ec2:*:*:launch-template/*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/for-use-with-amazon-emr-managed-policies": "true"
}
}
},
{
"Sid": "CreateEMRTaggedLaunchTemplate",
"Effect": "Allow",
"Action": [
"ec2:CreateLaunchTemplate"
],
"Resource": [
"arn:aws:ec2:*:*:launch-template/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/for-use-with-amazon-emr-managed-policies": "true"
}
}
},
{
"Sid": "CreateEMRTaggedInstancesAndVolumes",
"Effect": "Allow",
"Action": [
"ec2:RunInstances",
"ec2:CreateFleet"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ec2:*:*:volume/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/for-use-with-amazon-emr-managed-policies": "true"
}
}
},
{
"Sid": "ResourcesToLaunchEC2",
"Effect": "Allow",
"Action": [
"ec2:RunInstances",
"ec2:CreateFleet",
"ec2:CreateLaunchTemplate",
"ec2:CreateLaunchTemplateVersion"
],
"Resource": [
"arn:aws:ec2:*:*:network-interface/*",
"arn:aws:ec2:*::image/ami-*",
"arn:aws:ec2:*:*:key-pair/*",
"arn:aws:ec2:*:*:capacity-reservation/*",
"arn:aws:ec2:*:*:placement-group/pg-*",
"arn:aws:ec2:*:*:fleet/*",
"arn:aws:ec2:*:*:dedicated-host/*",
"arn:aws:resource-groups:*:*:group/*"
]
},
{
"Sid": "ManageEMRTaggedResources",
"Effect": "Allow",
"Action": [
"ec2:CreateLaunchTemplateVersion",
"ec2:DeleteLaunchTemplate",
"ec2:DeleteNetworkInterface",
"ec2:ModifyInstanceAttribute",
"ec2:TerminateInstances"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/for-use-with-amazon-emr-managed-policies": "true"
}
}
},
{
"Sid": "ManageTagsOnEMRTaggedResources",
"Effect": "Allow",
"Action": [
"ec2:CreateTags",
"ec2:DeleteTags"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:network-interface/*",
"arn:aws:ec2:*:*:launch-template/*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/for-use-with-amazon-emr-managed-policies": "true"
}
}
},
{
"Sid": "CreateNetworkInterfaceNeededForPrivateSubnet",
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface"
],
"Resource": [
"arn:aws:ec2:*:*:network-interface/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/for-use-with-amazon-emr-managed-policies": "true"
}
}
},
{
"Sid": "TagOnCreateTaggedEMRResources",
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": [
"arn:aws:ec2:*:*:network-interface/*",
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:launch-template/*"
],
"Condition": {
"StringEquals": {
"ec2:CreateAction": [
"RunInstances",
"CreateFleet",
"CreateLaunchTemplate",
"CreateNetworkInterface"
]
}
}
},
{
"Sid": "TagPlacementGroups",
"Effect": "Allow",
"Action": [
"ec2:CreateTags",
"ec2:DeleteTags"
],
"Resource": [
"arn:aws:ec2:*:*:placement-group/pg-*"
]
},
{
"Sid": "ListActionsForEC2Resources",
"Effect": "Allow",
"Action": [
"ec2:DescribeAccountAttributes",
"ec2:DescribeCapacityReservations",
"ec2:DescribeDhcpOptions",
"ec2:DescribeImages",
"ec2:DescribeInstances",
"ec2:DescribeInstanceTypeOfferings",
"ec2:DescribeLaunchTemplates",
"ec2:DescribeNetworkAcls",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribePlacementGroups",
"ec2:DescribeRouteTables",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVolumes",
"ec2:DescribeVolumeStatus",
"ec2:DescribeVpcAttribute",
"ec2:DescribeVpcEndpoints",
"ec2:DescribeVpcs"
],
"Resource": [
"*"
]
},
{
"Sid": "CreateDefaultSecurityGroupWithEMRTags",
"Effect": "Allow",
"Action": [
"ec2:CreateSecurityGroup"
],
"Resource": [
"arn:aws:ec2:*:*:security-group/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/for-use-with-amazon-emr-managed-policies": "true"
}
}
},
{
"Sid": "CreateDefaultSecurityGroupInVPCWithEMRTags",
"Effect": "Allow",
"Action": [
"ec2:CreateSecurityGroup"
],
"Resource": [
"arn:aws:ec2:*:*:vpc/*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/for-use-with-amazon-emr-managed-policies": "true"
}
}
},
{
"Sid": "TagOnCreateDefaultSecurityGroupWithEMRTags",
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": [
"arn:aws:ec2:*:*:security-group/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/for-use-with-amazon-emr-managed-policies": "true",
"ec2:CreateAction": "CreateSecurityGroup"
}
}
},
{
"Sid": "ManageSecurityGroups",
"Effect": "Allow",
"Action": [
"ec2:AuthorizeSecurityGroupEgress",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:RevokeSecurityGroupEgress",
"ec2:RevokeSecurityGroupIngress"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/for-use-with-amazon-emr-managed-policies": "true"
}
}
},
{
"Sid": "CreateEMRPlacementGroups",
"Effect": "Allow",
"Action": [
"ec2:CreatePlacementGroup"
],
"Resource": [
"arn:aws:ec2:*:*:placement-group/pg-*"
]
},
{
"Sid": "DeletePlacementGroups",
"Effect": "Allow",
"Action": [
"ec2:DeletePlacementGroup"
],
"Resource": [
"*"
]
},
{
"Sid": "AutoScaling",
"Effect": "Allow",
"Action": [
"application-autoscaling:DeleteScalingPolicy",
"application-autoscaling:DeregisterScalableTarget",
"application-autoscaling:DescribeScalableTargets",
"application-autoscaling:DescribeScalingPolicies",
"application-autoscaling:PutScalingPolicy",
"application-autoscaling:RegisterScalableTarget"
],
"Resource": [
"*"
]
},
{
"Sid": "ResourceGroupsForCapacityReservations",
"Effect": "Allow",
"Action": [
"resource-groups:ListGroupResources"
],
"Resource": [
"*"
]
},
{
"Sid": "AutoScalingCloudWatch",
"Effect": "Allow",
"Action": [
"cloudwatch:PutMetricAlarm",
"cloudwatch:DeleteAlarms",
"cloudwatch:DescribeAlarms"
],
"Resource": [
"arn:aws:cloudwatch:*:*:alarm:*_EMR_Auto_Scaling"
]
},
{
"Sid": "PassRoleForAutoScaling",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::*:role/EMR_AutoScaling_DefaultRole"
],
"Condition": {
"StringLike": {
"iam:PassedToService": "application-autoscaling.amazonaws.com*"
}
}
},
{
"Sid": "PassRoleForEC2",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::*:role/EMR_EC2_DefaultRole"
],
"Condition": {
"StringLike": {
"iam:PassedToService": "ec2.amazonaws.com*"
}
}
},
{
"Sid": "CreateAndModifyEmrServiceVPCEndpoint",
"Effect": "Allow",
"Action": [
"ec2:ModifyVpcEndpoint",
"ec2:CreateVpcEndpoint"
],
"Resource": [
"arn:aws:ec2:*:*:vpc-endpoint/*",
"arn:aws:ec2:*:*:subnet/*",
"arn:aws:ec2:*:*:security-group/*",
"arn:aws:ec2:*:*:vpc/*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/for-use-with-amazon-emr-managed-policies": "true"
}
}
},
{
"Sid": "CreateEmrServiceVPCEndpoint",
"Effect": "Allow",
"Action": [
"ec2:CreateVpcEndpoint"
],
"Resource": [
"arn:aws:ec2:*:*:vpc-endpoint/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/for-use-with-amazon-emr-managed-policies": "true",
"aws:RequestTag/Name": "emr-service-vpce"
}
}
},
{
"Sid": "TagEmrServiceVPCEndpoint",
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": [
"arn:aws:ec2:*:*:vpc-endpoint/*"
],
"Condition": {
"StringEquals": {
"ec2:CreateAction": "CreateVpcEndpoint",
"aws:RequestTag/for-use-with-amazon-emr-managed-policies": "true",
"aws:RequestTag/Name": "emr-service-vpce"
}
}
}
]
}
```
------
Ihre Servicerolle sollte die folgende Vertrauensrichtlinie verwenden.
**Wichtig**
Die folgende Vertrauensrichtlinie umfasst die globalen Bedingungsschlüssel [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) und [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount), die die Berechtigungen einschränken, die Sie Amazon EMR auf bestimmte Ressourcen in Ihrem Konto erteilen. Auf diese Weise können Sie sich vor dem [Problem des verwirrten Stellvertreters](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) schützen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSTSAssumerole",
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": "arn:aws:iam::123456789012:role/EMRServiceRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:elasticmapreduce:*:123456789012:*"
}
}
}
]
}
```
------
# Servicerolle für EC2-Cluster-Instances (EC2-Instance-Profil)
Die Servicerolle für EC2-Instance-Cluster (auch als EC2-Instance-Profil für Amazon EMR bezeichnet) ist eine spezielle Art von Servicerolle, die jeder EC2-Instance in einem Amazon-EMR-Cluster zugewiesen wird, wenn die Instance startet. Anwendungsprozesse, die auf der Hadoop-Ökosystem ausgeführt werden, übernehmen diese Rolle für Berechtigungen für die Interaktion mit anderen AWS -Services.
Weitere Informationen zu Servicerollen für EC2-Instances finden Sie unter [Verwenden einer IAM-Rolle zum Erteilen von Berechtigungen für Anwendungen, die auf Amazon-EC2-Instances ausgeführt werden](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html) im *IAM-Benutzerhandbuch*.
**Wichtig**
Die Standarddienstrolle für Cluster-EC2-Instances und die zugehörige verwaltete AWS Standardrichtlinie `AmazonElasticMapReduceforEC2Role` sind inzwischen veraltet, und es werden keine neuen AWS verwalteten Richtlinien bereitgestellt. Sie müssen ein Instance-Profil erstellen und angeben, um die veraltete Rolle und die Standardrichtlinie zu ersetzen.
## Standardrolle und verwaltete Richtlinie
+ Der Standardrollenname ist `EMR_EC2_DefaultRole`.
+ Die `EMR_EC2_DefaultRole` standardmäßige verwaltete Richtlinie,`AmazonElasticMapReduceforEC2Role`, nähert sich dem Ende des Supports. Anstatt eine verwaltete Standardrichtlinie für das EC2-Instance-Profil zu verwenden, wenden Sie ressourcenbasierte Richtlinien auf S3-Buckets und andere Ressourcen an, die Amazon EMR benötigt, oder verwenden Sie Ihre eigene, vom Kunden verwaltete Richtlinie mit einer IAM-Rolle als Instance-Profil. Weitere Informationen finden Sie unter [Erstellen einer Servicerolle für EC2-Cluster-Instances mit Berechtigungen mit geringsten Rechten](#emr-ec2-role-least-privilege).
Im Folgenden werden die Inhalte von Version 3 von `AmazonElasticMapReduceforEC2Role` gezeigt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Resource": [
"*"
],
"Action": [
"cloudwatch:*",
"dynamodb:*",
"ec2:Describe*",
"elasticmapreduce:Describe*",
"elasticmapreduce:ListBootstrapActions",
"elasticmapreduce:ListClusters",
"elasticmapreduce:ListInstanceGroups",
"elasticmapreduce:ListInstances",
"elasticmapreduce:ListSteps",
"kinesis:CreateStream",
"kinesis:DeleteStream",
"kinesis:DescribeStream",
"kinesis:GetRecords",
"kinesis:GetShardIterator",
"kinesis:MergeShards",
"kinesis:PutRecord",
"kinesis:SplitShard",
"rds:Describe*",
"s3:*",
"sdb:*",
"sns:*",
"sqs:*",
"glue:CreateDatabase",
"glue:UpdateDatabase",
"glue:DeleteDatabase",
"glue:GetDatabase",
"glue:GetDatabases",
"glue:CreateTable",
"glue:UpdateTable",
"glue:DeleteTable",
"glue:GetTable",
"glue:GetTables",
"glue:GetTableVersions",
"glue:CreatePartition",
"glue:BatchCreatePartition",
"glue:UpdatePartition",
"glue:DeletePartition",
"glue:BatchDeletePartition",
"glue:GetPartition",
"glue:GetPartitions",
"glue:BatchGetPartition",
"glue:CreateUserDefinedFunction",
"glue:UpdateUserDefinedFunction",
"glue:DeleteUserDefinedFunction",
"glue:GetUserDefinedFunction",
"glue:GetUserDefinedFunctions"
],
"Sid": "AllowCLOUDWATCH"
}
]
}
```
------
Ihre Servicerolle sollte die folgende Vertrauensrichtlinie verwenden.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSTSAssumerole",
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": "arn:aws:iam::123456789012:role/EMR_EC2_DefaultRole"
}
]
}
```
------
## Erstellen einer Servicerolle für EC2-Cluster-Instances mit Berechtigungen mit geringsten Rechten
Als bewährte Methode empfehlen wir dringend, eine Servicerolle für Cluster-EC2-Instances und eine Berechtigungsrichtlinie zu erstellen, die über die Mindestberechtigungen für andere AWS Dienste verfügt, die für Ihre Anwendung erforderlich sind.
Die standardmäßige verwaltete Richtlinie, `AmazonElasticMapReduceforEC2Role`, bietet Berechtigungen, mit denen Sie problemlos einen ersten Cluster starten können. `AmazonElasticMapReduceforEC2Role`ist jedoch auf dem Weg, veraltet zu werden, und Amazon EMR wird keine AWS Ersatz-verwaltete Standardrichtlinie für die veraltete Rolle bereitstellen. Um einen ersten Cluster zu starten, müssen Sie eine vom Kunden verwaltete, ressourcenbasierte oder ID-basierte Richtlinie bereitstellen.
Die Richtlinienanweisungen unten zeigen Beispiele für die für verschiedene Features von Amazon EMR erforderlichen Berechtigungen. Wir empfehlen, diese Berechtigungen zu verwenden, um eine Berechtigungsrichtlinie zu erstellen, die den Zugriff auf nur diese Funktionen und Ressourcen beschränkt, die Ihr Cluster erfordert. Alle Beispielrichtlinien verwenden die *us-west-2* Region und die fiktive Konto-ID. AWS *123456789012* Ersetzen Sie diese je nach Bedarf für Ihren Cluster.
Weitere Informationen zum Erstellen und Angeben benutzerdefinierter Rollen finden Sie unter [Passen Sie IAM-Rollen mit Amazon EMR an](emr-iam-roles-custom.md).
**Anmerkung**
Wenn Sie eine benutzerdefinierte EMR-Rolle für EC2 erstellen, folgen Sie dem grundlegenden Workflow, der automatisch ein Instance-Profil mit demselben Namen erstellt. Amazon EC2 ermöglicht es Ihnen, Instance-Profile und Rollen mit unterschiedlichen Namen zu erstellen, aber Amazon EMR unterstützt diese Konfiguration nicht und führt zu einem Fehler „Ungültiges Instance-Profil“, wenn Sie den Cluster erstellen.
### Lesen und Schreiben von Daten in Amazon S3 mithilfe von EMRFS
Wenn eine Anwendung, die auf einem Amazon-EMR-Cluster ausgeführt wird, auf Daten mithilfe des `s3://mydata`-Formats verweist, wird Amazon EMR von EC2-Instance-Profilen verwendet, um die Anforderung zu stellen. Cluster lesen und schreiben in der Regel Daten auf diese Weise in Amazon S3 und EMRFS verwendet die Amazon-EMR-Berechtigungen, die standardmäßig an die Servicerolle für EC2 Instances angefügt sind. Weitere Informationen finden Sie unter [Konfigurieren von IAM-Rollen für EMRFS-Anforderungen an Amazon S3](emr-emrfs-iam-roles.md).
Da IAM-Rollen für EMRFS auf die Berechtigungen zurückgreifen, die der Servicerolle für Cluster-EC2-Instances zugeordnet sind, empfehlen wir als bewährte Methode, IAM-Rollen für EMRFS zu verwenden und die EMRFS- und Amazon-S3-Berechtigungen, die der Servicerolle zugeordnet sind, für Cluster-EC2-Instances einzuschränken.
Die Beispielanweisung unten zeigt die Berechtigungen, die erforderlich sind, damit EMRFS Anforderungen an Amazon S3 senden kann.
+ *my-data-bucket-in-s3-for-emrfs-reads-and-writes* spezifiziert den Bucket in Amazon S3, mit den der Cluster Daten liest und schreibt, sowie alle Unterordner mit */\$1*. Fügen Sie nur die Buckets und Ordner hinzu, die Ihre Anwendung benötigt.
+ Die Richtlinienerklärung, die `dynamodb`-Aktionen zulässt, ist nur erforderlich, wenn die konsistente EMRFS-Ansicht aktiviert ist. *EmrFSMetadata* gibt den Standardordner für die konsistente EMRFS-Ansicht an.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:AbortMultipartUpload",
"s3:CreateBucket",
"s3:DeleteObject",
"s3:GetBucketVersioning",
"s3:GetObject",
"s3:GetObjectTagging",
"s3:GetObjectVersion",
"s3:ListBucket",
"s3:ListBucketMultipartUploads",
"s3:ListBucketVersions",
"s3:ListMultipartUploadParts",
"s3:PutBucketVersioning",
"s3:PutObject",
"s3:PutObjectTagging"
],
"Resource": [
"arn:aws:s3:::my-data-bucket-in-s3-for-emrfs-reads-and-writes",
"arn:aws:s3:::my-data-bucket-in-s3-for-emrfs-reads-and-writes/*"
],
"Sid": "AllowS3Abortmultipartupload"
},
{
"Effect": "Allow",
"Action": [
"dynamodb:CreateTable",
"dynamodb:BatchGetItem",
"dynamodb:BatchWriteItem",
"dynamodb:PutItem",
"dynamodb:DescribeTable",
"dynamodb:DeleteItem",
"dynamodb:GetItem",
"dynamodb:Scan",
"dynamodb:Query",
"dynamodb:UpdateItem",
"dynamodb:DeleteTable",
"dynamodb:UpdateTable"
],
"Resource": [
"arn:aws:dynamodb:*:123456789012:table/EmrFSMetadata"
],
"Sid": "AllowDYNAMODBCreatetable"
},
{
"Effect": "Allow",
"Action": [
"cloudwatch:PutMetricData",
"dynamodb:ListTables",
"s3:ListBucket"
],
"Resource": [
"*"
],
"Sid": "AllowCLOUDWATCHPutmetricdata"
},
{
"Effect": "Allow",
"Action": [
"sqs:GetQueueUrl",
"sqs:ReceiveMessage",
"sqs:DeleteQueue",
"sqs:SendMessage",
"sqs:CreateQueue"
],
"Resource": [
"arn:aws:sqs:*:123456789012:EMRFS-Inconsistency-*"
],
"Sid": "AllowSQSGetqueueurl"
}
]
}
```
------
### Archivieren von Protokolldateien in Amazon S3
Die folgende Richtlinienanweisung ermöglicht dem Amazon-EMR-Cluster die Archivierung von Protokolldateien in dem angegebenen Amazon-S3-Speicherort. Im folgenden Beispiel wurde bei der Erstellung des Clusters der **Speicherort Protokollordner S3** in der Konsole, mithilfe der `--log-uri` Option von oder mithilfe des AWS CLI`LogUri` Parameters im `RunJobFlow` Befehl angegeben. *s3://MyLoggingBucket/MyEMRClusterLogs* Weitere Informationen finden Sie unter [Archivieren von Protokolldateien in Amazon S3](emr-plan-debugging.md#emr-plan-debugging-logs-archive).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObject"
],
"Resource": [
"arn:aws:s3:::MyLoggingBucket/MyEMRClusterLogs/*"
],
"Sid": "AllowS3Putobject"
}
]
}
```
------
### Verwenden des AWS Glue-Datenkatalogs
Die folgende Richtlinienerklärung erlaubt Aktionen, die erforderlich sind, wenn Sie den AWS Glue-Datenkatalog als Metastore für Anwendungen verwenden. Weitere Informationen finden Sie unter [Verwenden des AWS Glue-Datenkatalogs als Metastore für Spark SQL](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-glue.html), [Verwenden des AWS Glue-Datenkatalogs als Metastore für Hive](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hive-metastore-glue.html) und [Verwenden von Presto mit dem AWS Glue-Datenkatalog](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-presto-glue.html) im *Amazon* EMR-Versionshandbuch.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"glue:CreateDatabase",
"glue:UpdateDatabase",
"glue:DeleteDatabase",
"glue:GetDatabase",
"glue:GetDatabases",
"glue:CreateTable",
"glue:UpdateTable",
"glue:DeleteTable",
"glue:GetTable",
"glue:GetTables",
"glue:GetTableVersions",
"glue:CreatePartition",
"glue:BatchCreatePartition",
"glue:UpdatePartition",
"glue:DeletePartition",
"glue:BatchDeletePartition",
"glue:GetPartition",
"glue:GetPartitions",
"glue:BatchGetPartition",
"glue:CreateUserDefinedFunction",
"glue:UpdateUserDefinedFunction",
"glue:DeleteUserDefinedFunction",
"glue:GetUserDefinedFunction",
"glue:GetUserDefinedFunctions"
],
"Resource": [
"*"
],
"Sid": "AllowGLUECreatedatabase"
}
]
}
```
------
# Servicerolle für Auto Scaling in Amazon EMR (Auto Scaling-Rolle)
Die Auto-Scaling-Rolle für Amazon EMR führt eine ähnliche Funktion aus wie die Servicerolle, ermöglicht aber zusätzliche Aktionen für dynamisch skalierte Umgebungen.
+ Der Standardrollenname ist `EMR_AutoScaling_DefaultRole`.
+ Die an `EMR_AutoScaling_DefaultRole` angefügte standardmäßige verwaltete Richtlinie ist `AmazonElasticMapReduceforAutoScalingRole`.
Der Inhalt von Version 1 `AmazonElasticMapReduceforAutoScalingRole` wird unten angezeigt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"cloudwatch:DescribeAlarms",
"elasticmapreduce:ListInstanceGroups",
"elasticmapreduce:ModifyInstanceGroups"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Sid": "AllowCLOUDWATCHDescribealarms"
}
]
}
```
------
Ihre Servicerolle sollte die folgende Vertrauensrichtlinie verwenden.
**Wichtig**
Die folgende Vertrauensrichtlinie umfasst die globalen Bedingungsschlüssel [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) und [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount), die die Berechtigungen einschränken, die Sie Amazon EMR auf bestimmte Ressourcen in Ihrem Konto erteilen. Auf diese Weise können Sie sich vor dem [Problem des verwirrten Stellvertreters](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) schützen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": "arn:aws:iam::123456789012:role/ApplicationAutoScalingEMRRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:application-autoscaling:*:123456789012:scalable-target/*"
}
},
"Sid": "AllowSTSAssumerole"
}
]
}
```
------
# Servicerolle für EMR Notebooks
Jedes EMR-Notizbuch benötigt Berechtigungen, um auf andere AWS Ressourcen zuzugreifen und Aktionen auszuführen. Die mit dieser Servicerolle verknüpften IAM-Richtlinien gewähren dem Notebook Berechtigungen für die Zusammenarbeit mit anderen Diensten. AWS Wenn Sie mit dem ein Notebook erstellen AWS-Managementkonsole, geben Sie eine *AWS Servicerolle* an. Sie können die Standardrolle, `EMR_Notebooks_DefaultRole`, verwenden oder eine Rolle angeben, die Sie erstellen. Wenn ein Notebook nicht vorher erstellt wurde, haben Sie die Möglichkeit, die Standardrolle zu erstellen.
+ Der Standardrollenname ist `EMR_Notebooks_DefaultRole`.
+ Die standardmäßig angehängten verwalteten Richtlinien zu `EMR_Notebooks_DefaultRole` sind `AmazonElasticMapReduceEditorsRole` und `S3FullAccessPolicy`.
Ihre Servicerolle sollte die folgende Vertrauensrichtlinie verwenden.
**Wichtig**
Die folgende Vertrauensrichtlinie umfasst die globalen Bedingungsschlüssel [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) und [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount), die die Berechtigungen einschränken, die Sie Amazon EMR auf bestimmte Ressourcen in Ihrem Konto erteilen. Auf diese Weise können Sie sich vor dem [Problem des verwirrten Stellvertreters](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) schützen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": "arn:aws:iam::123456789012:role/EMRServiceRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:elasticmapreduce:*:123456789012:*"
}
},
"Sid": "AllowSTSAssumerole"
}
]
}
```
------
Der Inhalt von Version 1 von `AmazonElasticMapReduceEditorsRole` lautet wie folgt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:AuthorizeSecurityGroupEgress",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:CreateSecurityGroup",
"ec2:DescribeSecurityGroups",
"ec2:RevokeSecurityGroupEgress",
"ec2:CreateNetworkInterface",
"ec2:CreateNetworkInterfacePermission",
"ec2:DeleteNetworkInterface",
"ec2:DeleteNetworkInterfacePermission",
"ec2:DescribeNetworkInterfaces",
"ec2:ModifyNetworkInterfaceAttribute",
"ec2:DescribeTags",
"ec2:DescribeInstances",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"elasticmapreduce:ListInstances",
"elasticmapreduce:DescribeCluster",
"elasticmapreduce:ListSteps"
],
"Resource": [
"*"
],
"Sid": "AllowEC2Authorizesecuritygroupegress"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": [
"arn:aws:ec2:*:*:network-interface/*"
],
"Condition": {
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"aws:elasticmapreduce:editor-id",
"aws:elasticmapreduce:job-flow-id"
]
}
},
"Sid": "AllowEC2Createtags"
}
]
}
```
------
Im Folgenden sehen Sie den Inhalt von `S3FullAccessPolicy`. `S3FullAccessPolicy` Dadurch kann Ihre Servicerolle für EMR Notebooks alle Amazon S3-Aktionen an Objekten in Ihrem AWS-Konto ausführen. Wenn Sie eine benutzerdefinierte Servicerolle für EMR Notebooks erstellen, müssen Sie Ihrer Servicerolle Amazon-S3-Berechtigungen erteilen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": [
"*"
],
"Sid": "AllowS3"
}
]
}
```
------
Sie können den Lese- und Schreibzugriff für Ihre Servicerolle auf den Amazon-S3-Standort beschränken, an dem Sie Ihre Notebookdateien speichern möchten. Verwenden Sie die folgenden Mindestberechtigungen an Amazon S3.
```
"s3:PutObject",
"s3:GetObject",
"s3:GetEncryptionConfiguration",
"s3:ListBucket",
"s3:DeleteObject"
```
Wenn Ihr Amazon-S3-Bucket verschlüsselt ist, müssen Sie die folgenden Berechtigungen für AWS Key Management Service angeben.
```
"kms:Decrypt",
"kms:GenerateDataKey",
"kms:ReEncryptFrom",
"kms:ReEncryptTo",
"kms:DescribeKey"
```
Wenn Sie Git-Repositorys mit Ihrem Notebook verknüpfen und ein Geheimnis für das Repository erstellen müssen, müssen Sie die Berechtigung `secretsmanager:GetSecretValue` in der IAM-Richtlinie hinzufügen, die der Servicerolle für Amazon EMR Notebooks zugewiesen ist. Eine Beispielrichtlinie wird nachfolgend gezeigt:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue"
],
"Resource": [
"*"
]
}
]
}
```
------
## Berechtigungen für die Servicerolle von EMR Notebooks
In dieser Tabelle sind die Aktionen aufgeführt, die EMR Notebooks mithilfe der Servicerolle durchführt, zusammen mit den Berechtigungen, die für jede Aktion erforderlich sind.
****
| Action | Berechtigungen |
| --- | --- |
| Richten Sie einen sicheren Netzwerkkanal zwischen einem Notebook und einem Amazon-EMR-Cluster ein und führen Sie die erforderlichen Bereinigungsaktionen durch. | "ec2:CreateNetworkInterface",
"ec2:CreateNetworkInterfacePermission",
"ec2:DeleteNetworkInterface",
"ec2:DeleteNetworkInterfacePermission",
"ec2:DescribeNetworkInterfaces",
"ec2:ModifyNetworkInterfaceAttribute",
"ec2:AuthorizeSecurityGroupEgress",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:CreateSecurityGroup",
"ec2:DescribeSecurityGroups",
"ec2:RevokeSecurityGroupEgress",
"ec2:DescribeTags",
"ec2:DescribeInstances",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"elasticmapreduce:ListInstances",
"elasticmapreduce:DescribeCluster",
"elasticmapreduce:ListSteps"
|
| Verwenden Sie die in gespeicherten Git-Anmeldeinformationen AWS Secrets Manager , um Git-Repositorys mit einem Notizbuch zu verknüpfen. | "secretsmanager:GetSecretValue"
|
| Wenden Sie AWS Tags auf die Netzwerkschnittstelle und die Standardsicherheitsgruppen an, die EMR Notebooks bei der Einrichtung des sicheren Netzwerkkanals erstellt. Weitere Informationen finden Sie unter [Markieren von AWS -Ressourcen](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html). | "ec2:CreateTags"
|
| Greifen Sie auf Notebook-Dateien und Metadaten zu oder laden Sie sie in Amazon S3 hoch. | "s3:PutObject",
"s3:GetObject",
"s3:GetEncryptionConfiguration",
"s3:ListBucket",
"s3:DeleteObject"
Wenn Sie einen verschlüsselten Amazon-S3-Bucket verwenden, sind die folgenden Berechtigungen erforderlich. "kms:Decrypt",
"kms:GenerateDataKey",
"kms:ReEncryptFrom",
"kms:ReEncryptTo",
"kms:DescribeKey"
|
## Aktualisierungen der AWS verwalteten Richtlinien von EMR Notebooks
Hier finden Sie Details zu Aktualisierungen der AWS verwalteten Richtlinien für EMR Notebooks seit dem 1. März 2021.
| Änderungen | Beschreibung | Date |
| --- | --- | --- |
| AmazonElasticMapReduceEditorsRole - Added permissions | EMR Notebooks fügt `ec2:describeVPCs`- und `elastmicmapreduce:ListSteps`-Berechtigungen für `AmazonElasticMapReduceEditorsRole` hinzu. | 8. Februar 2023 |
| EMR Notebooks hat damit begonnen, Änderungen zu verfolgen | EMR Notebooks begann, Änderungen an seinen AWS verwalteten Richtlinien nachzuverfolgen. | 8. Februar 2023 |
# Verwenden von serviceverknüpften Rollen für Amazon EMR
Amazon EMR verwendet AWS Identity and Access Management (IAM) [serviceverknüpfte](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) Rollen. Eine serviceverknüpfte Rolle ist eine einzigartige Art von IAM-Rolle, die direkt mit Amazon EMR verknüpft ist. Servicebezogene Rollen sind von Amazon EMR vordefiniert und beinhalten alle Berechtigungen, die der Service benötigt, um andere AWS Services in Ihrem Namen aufzurufen.
**Topics**
+ [Verwenden von serviceverknüpften Rollen für Amazon EMR zur Bereinigung](using-service-linked-roles-cleanup.md)
+ [Verwenden von serviceverknüpften Rollen mit Amazon EMR für die Write-Ahead-Protokollierung](using-service-linked-roles-wal.md)
**Informationen zu anderen Diensten, die serviceverknüpfte Rollen unterstützen, finden Sie unter [AWS Dienste, die mit IAM funktionieren](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). Suchen Sie in der Spalte Serviceverknüpfte Rollen nach den Diensten, für die **Ja** steht.** Wählen Sie über einen Link **Ja** aus, um die Dokumentation zu einer serviceverknüpften Rolle für diesen Service anzuzeigen.
# Verwenden von serviceverknüpften Rollen für Amazon EMR zur Bereinigung
Amazon EMR verwendet AWS Identity and Access Management (IAM) [serviceverknüpfte](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) Rollen. Eine serviceverknüpfte Rolle ist eine einzigartige Art von IAM-Rolle, die direkt mit Amazon EMR verknüpft ist. Servicebezogene Rollen sind von Amazon EMR vordefiniert und beinhalten alle Berechtigungen, die der Service benötigt, um andere AWS Services in Ihrem Namen aufzurufen.
Serviceverknüpfte Rollen arbeiten mit der Amazon EMR-Servicerolle und dem Amazon EC2 EC2-Instance-Profil für Amazon EMR zusammen. Weitere Informationen über die Service-Rolle und das Instance-Profil finden Sie unter [Konfiguration von IAM-Servicerollen für Amazon EMR-Berechtigungen für AWS Dienste und Ressourcen](emr-iam-roles.md).
Eine serviceverknüpfte Rolle erleichtert die Einrichtung von Amazon EMR, da Sie die erforderlichen Berechtigungen nicht manuell hinzufügen müssen. Amazon EMR definiert die Berechtigungen seiner serviceverknüpften Rollen, und sofern nicht anders definiert, kann nur Amazon EMR seine Rollen übernehmen. Die definierten Berechtigungen umfassen die Vertrauens- und Berechtigungsrichtlinie. Diese Berechtigungsrichtlinie kann keinen anderen IAM-Entitäten zugewiesen werden.
Sie können diese serviceverknüpfte Rolle für Amazon EMR erst löschen, nachdem Sie alle zugehörigen Ressourcen gelöscht und alle EMR-Cluster im Konto beendet haben. Dadurch werden Ihre Amazon EMR-Ressourcen geschützt, sodass Sie nicht versehentlich die Zugriffsberechtigung für die Ressourcen entziehen können.
## Verwenden von Rollen, die mit Services verknüpft sind, für die Bereinigung
Amazon EMR verwendet die servicebasierte **AWSServiceRoleForEMRCleanup**Rolle, um Amazon EMR die Erlaubnis zu erteilen, Amazon EC2 EC2-Ressourcen in Ihrem Namen zu beenden und zu löschen, falls die mit dem Amazon EMR-Service verknüpfte Rolle diese Funktion verliert. Amazon EMR erstellt die serviceverknüpfte Rolle automatisch während der Clustererstellung, sofern sie noch nicht vorhanden ist.
Die AWSService RoleFor EMRCleanup serviceverknüpfte Rolle vertraut darauf, dass die folgenden Services die Rolle übernehmen:
+ `elasticmapreduce.amazonaws.com`
Die Richtlinie für AWSService RoleFor EMRCleanup servicebezogene Rollenberechtigungen ermöglicht es Amazon EMR, die folgenden Aktionen für die angegebenen Ressourcen durchzuführen:
+ Aktion: `DescribeInstances` für `ec2`
+ Aktion: `DescribeLaunchTemplates` für `ec2`
+ Aktion: `DeleteLaunchTemplate` für `ec2`
+ Aktion: `DescribeSpotInstanceRequests` für `ec2`
+ Aktion: `ModifyInstanceAttribute` für `ec2`
+ Aktion: `TerminateInstances` für `ec2`
+ Aktion: `CancelSpotInstanceRequests` für `ec2`
+ Aktion: `DeleteNetworkInterface` für `ec2`
+ Aktion: `DescribeInstanceAttribute` für `ec2`
+ Aktion: `DescribeVolumeStatus` für `ec2`
+ Aktion: `DescribeVolumes` für `ec2`
+ Aktion: `DetachVolume` für `ec2`
+ Aktion: `DeleteVolume` für `ec2`
+ Aktion: `DescribePlacementGroups` für `ec2`
+ Aktion: `DeletePlacementGroup` für `ec2`
Sie müssen Berechtigungen konfigurieren, damit eine juristische Stelle von IAM (z. B. Benutzer, Gruppe oder Rolle) eine serviceverknüpfte Rolle erstellen, bearbeiten oder löschen kann.
## Erstellen einer serviceverknüpften Rolle für Amazon EMR
Sie müssen die Rolle nicht manuell erstellen. AWSService RoleFor EMRCleanup Wenn Sie einen Cluster starten, entweder zum ersten Mal oder wenn die AWSService RoleFor EMRCleanup serviceverknüpfte Rolle nicht vorhanden ist, erstellt Amazon EMR die AWSService RoleFor EMRCleanup serviceverknüpfte Rolle für Sie. Sie müssen über die erforderlichen Berechtigungen verfügen, um eine serviceverknüpfte Rolle zu erstellen. Für eine Beispielanweisung, die diese Funktion zur Berechtigungsrichtlinie einer IAM-Entität (z. B. eines Benutzers, einer Gruppe oder einer Rolle) hinzufügt:
Fügen Sie der Berechtigungsrichtlinie für die IAM-Entität, die die dienstverknüpfte Rolle erstellen muss, die folgende Anweisung hinzu.
```
{
"Sid": "ElasticMapReduceServiceLinkedRole",
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/elasticmapreduce.amazonaws.com*/AWSServiceRoleForEMRCleanup*",
"Condition": {
"StringEquals": {
"iam:AWSServiceName": [
"elasticmapreduce.amazonaws.com",
"elasticmapreduce.amazonaws.com.rproxy.govskope.ca.cn"
]
}
}
}
```
**Wichtig**
Wenn Sie Amazon EMR vor dem 24. Oktober 2017 verwendet haben, als serviceverknüpfte Rollen nicht unterstützt wurden, hat Amazon EMR die AWSService RoleFor EMRCleanup serviceverknüpfte Rolle in Ihrem Konto erstellt. Weitere Informationen finden Sie unter [In meinem IAM-Konto wird eine neue Rolle angezeigt](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared).
## Bearbeiten einer serviceverknüpften Rolle für Amazon EMR
Amazon EMR erlaubt es Ihnen nicht, die AWSService RoleFor EMRCleanup serviceverknüpfte Rolle zu bearbeiten. Nachdem Sie eine serviceverknüpfte Rolle erstellt haben, können Sie den Namen der serviceverknüpften Rolle nicht mehr ändern, da verschiedene Entitäten möglicherweise auf die serviceverknüpfte Rolle verweisen. Sie können die Beschreibung der dienstbezogenen Rolle jedoch mithilfe von IAM bearbeiten.
### Bearbeiten der Beschreibung einer serviceverknüpften Rolle (IAM-Konsole)
Sie können die IAM-Konsole für das Bearbeiten der Beschreibung einer serviceverknüpften Rolle verwenden.
**So bearbeiten Sie die Beschreibung einer serviceverknüpften Rolle (Konsole)**
1. Wählen Sie im Navigationsbereich der IAM Console **Roles** (Rollen) aus.
1. Wählen Sie den Namen der zu ändernden Rolle.
1. Wählen Sie neben **Rollenbeschreibung** rechts **Bearbeiten** aus.
1. Geben Sie eine neue Beschreibung im Dialogfeld ein und wählen Sie **Save changes** (Änderungen speichern).
### Bearbeiten der Beschreibung einer serviceverknüpften Rolle (IAM-CLI)
Sie können IAM-Befehle aus dem verwenden, AWS Command Line Interface um die Beschreibung einer serviceverknüpften Rolle zu bearbeiten.
**So ändern Sie die Beschreibung einer serviceverknüpften Rolle (CLI)**
1. (Optional) Um die aktuelle Beschreibung einer Rolle anzuzeigen, verwenden Sie die folgenden Befehle:
```
$ aws iam get-role --role-name role-name
```
Verwenden Sie den Rollennamen, nicht den ARN, um sich auf Rollen mit den CLI-Befehlen zu beziehen. Wenn eine Rolle zum Beispiel folgenden ARN hat: `arn:aws:iam::123456789012:role/myrole`, verweisen Sie auf die Rolle als **myrole**.
1. Um die Beschreibung einer serviceverknüpften Rolle zu aktualisieren, verwenden Sie einen der folgenden Befehle:
```
$ aws iam update-role-description --role-name role-name --description description
```
### Bearbeiten der Beschreibung einer serviceverknüpften Rolle (IAM-API)
Sie können die IAM-API für das Bearbeiten der Beschreibung einer serviceverknüpften Rolle verwenden.
**So ändern Sie die Beschreibung einer serviceverknüpften Rolle (API)**
1. (Optional) Um die aktuelle Beschreibung einer Rolle anzuzeigen, verwenden Sie den folgenden Befehl:
IAM-API: [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html)
1. Um die Beschreibung einer Rolle zu aktualisieren, verwenden Sie den folgenden Befehl:
IAM-API: [UpdateRoleDescription](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html)
## Löschen einer serviceverknüpften Rolle für Amazon EMR
Wenn Sie eine Funktion oder einen Dienst, für den eine dienstverknüpfte Rolle erforderlich ist, nicht mehr verwenden müssen, empfehlen wir, diese dienstverknüpfte Rolle zu löschen. Auf diese Weise haben Sie keine ungenutzte Entität, die nicht aktiv überwacht oder verwaltet wird. Sie müssen jedoch Ihre serviceverknüpfte Rolle zunächst bereinigen, bevor Sie sie löschen können.
### Bereinigen einer serviceverknüpften Rolle
Bevor Sie IAM verwenden können, um eine dienstverknüpfte Rolle zu löschen, müssen Sie zunächst sicherstellen, dass die dienstverknüpfte Rolle keine aktiven Sitzungen hat, und alle Ressourcen entfernen, die von der dienstbezogenen Rolle verwendet werden.
**So überprüfen Sie in der IAM-Konsole, ob die serviceverknüpfte Rolle über eine aktive Sitzung verfügt**
1. Öffnen Sie unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) die IAM-Konsole.
1. Wählen Sie im Navigationsbereich **Rollen**. Wählen Sie den Namen (nicht das Kontrollkästchen) der serviceverknüpften Rolle aus. AWSService RoleFor EMRCleanup
1. Wählen Sie auf der **Übersichtsseite** für die ausgewählte dienstverknüpfte Rolle **Access** Advisor aus.
1. Überprüfen Sie auf der Registerkarte **Access Advisor (Advisor aufrufen)** die jüngsten Aktivitäten für die serviceverknüpfte Rolle.
**Anmerkung**
Wenn Sie sich nicht sicher sind, ob Amazon EMR die AWSService RoleFor EMRCleanup serviceverknüpfte Rolle verwendet, können Sie versuchen, die serviceverknüpfte Rolle zu löschen. Wenn der Service die serviceverknüpfte Rolle verwendet, schlägt das Löschen fehl und Sie können die Regionen anzeigen, in denen die serviceverknüpfte Rolle verwendet wird. Wenn die dienstverknüpfte Rolle verwendet wird, müssen Sie warten, bis die Sitzung beendet ist, bevor Sie die dienstverknüpfte Rolle löschen können. Die Sitzung für eine serviceverknüpfte Rolle können Sie nicht widerrufen.
**Um Amazon EMR-Ressourcen zu entfernen, die verwendet werden von AWSService RoleFor EMRCleanup**
+ Beenden Sie alle Cluster in Ihrem Konto. Weitere Informationen finden Sie unter [Beenden Sie einen Amazon EMR-Cluster im Status „Start“, „Wird ausgeführt“ oder „Wartend“](UsingEMR_TerminateJobFlow.md).
### Löschen einer serviceverknüpften Rolle (IAM-Konsole)
Sie können die IAM-Konsole für das Löschen einer serviceverknüpften Rolle verwenden.
**So löschen Sie eine serviceverknüpfte Rolle (Konsole)**
1. Öffnen Sie unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) die IAM-Konsole.
1. Wählen Sie im Navigationsbereich **Rollen**. Aktivieren Sie das Kontrollkästchen neben AWSService RoleForEMRCleanup, nicht den Namen oder die Zeile selbst.
1. Wählen Sie für **Role actions** oben auf der Seite **Delete role** aus.
1. Überprüfen Sie im Bestätigungsdialogfeld die Daten, auf die der Dienst zuletzt zugegriffen hat. Aus diesen Daten geht hervor, wann jede der ausgewählten Rollen zuletzt auf einen AWS Dienst zugegriffen hat. Auf diese Weise können Sie leichter bestätigen, ob die Rolle derzeit aktiv ist. Wählen Sie **Yes, Delete**, um fortzufahren.
1. Sehen Sie sich die Benachrichtigungen in der IAM-Konsole an, um den Fortschritt der Löschung der serviceverknüpften Rolle zu überwachen. Da das Löschen der dienstverknüpften IAM-Rolle asynchron erfolgt, kann die Löschaufgabe erfolgreich sein oder fehlschlagen, nachdem Sie die dienstverknüpfte Rolle zum Löschen eingereicht haben. Wenn der Vorgang fehlschlägt, können Sie in den Benachrichtigungen **View details** oder **View Resources** auswählen, um zu erfahren, warum die Löschung fehlgeschlagen ist. Wenn das Löschen fehlschlägt, weil der Service Ressourcen enthält, die von der Rolle verwendet werden, enthält die Angabe des Fehlergrundes eine Liste der Ressourcen.
### Löschen einer serviceverknüpften Rolle (IAM-CLI)
Sie können IAM-Befehle von verwenden, um eine dienstverknüpfte Rolle AWS Command Line Interface zu löschen. Da eine serviceverknüpfte Rolle nicht gelöscht werden kann, wenn sie verwendet wird oder ihr Ressourcen zugeordnet sind, müssen Sie eine Löschungsanforderung übermitteln. Wenn diese Bedingungen nicht erfüllt sind, kann diese Anforderung verweigert werden.
**So löschen Sie eine serviceverknüpfte Rolle (CLI)**
1. Sie benötigen die `deletion-task-id` aus der Antwort, um den Status der Löschaufgabe zu überprüfen. Geben Sie den folgenden Befehl ein, um eine Löschanforderung für eine serviceverknüpfte Rolle zu übermitteln:
```
$ aws iam [delete-service-linked-role](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-service-linked-role.html) --role-name AWSServiceRoleForEMRCleanup
```
1. Geben Sie den folgenden Befehl ein, um den Status der Löschaufgabe zu überprüfen:
```
$ aws iam [get-service-linked-role-deletion-status](https://docs.aws.amazon.com/cli/latest/reference/iam/get-service-linked-role-deletion-status.html) --deletion-task-id deletion-task-id
```
Der Status der Löschaufgabe kann `NOT_STARTED`, `IN_PROGRESS`, `SUCCEEDED` oder `FAILED` lauten. Wenn die Löschung fehlschlägt, gibt der Aufruf den Grund zurück, sodass Sie das Problem beheben können.
### Löschen einer serviceverknüpften Rolle (IAM-API)
Sie können die IAM-API zum Löschen einer serviceverknüpften Rolle verwenden. Da eine serviceverknüpfte Rolle nicht gelöscht werden kann, wenn sie verwendet wird oder ihr Ressourcen zugeordnet sind, müssen Sie eine Löschungsanforderung übermitteln. Wenn diese Bedingungen nicht erfüllt sind, kann diese Anforderung verweigert werden.
**So löschen Sie eine serviceverknüpfte Rolle (API)**
1. Rufen Sie an, um eine Löschanfrage für eine dienstverknüpfte Rolle einzureichen. [DeleteServiceLinkedRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteServiceLinkedRole.html) Geben Sie in der Anfrage den AWSService RoleFor EMRCleanup Rollennamen an.
Sie benötigen die `DeletionTaskId` aus der Antwort, um den Status der Löschaufgabe zu überprüfen.
1. Um den Status der Löschung zu überprüfen, rufen Sie [GetServiceLinkedRoleDeletionStatus](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetServiceLinkedRoleDeletionStatus.html) auf. Geben Sie in der Anforderung die `DeletionTaskId` an.
Der Status der Löschaufgabe kann `NOT_STARTED`, `IN_PROGRESS`, `SUCCEEDED` oder `FAILED` lauten. Wenn die Löschung fehlschlägt, gibt der Aufruf den Grund zurück, sodass Sie das Problem beheben können.
## Unterstützte Regionen für AWSService RoleFor EMRCleanup
Amazon EMR unterstützt die Verwendung der AWSService RoleFor EMRCleanup serviceverknüpften Rolle in den folgenden Regionen.
****
| Name der Region | Regions-ID | Amazon EMR Support |
| --- | --- | --- |
| USA Ost (Nord-Virginia) | us-east-1 | Ja |
| USA Ost (Ohio) | us-east-2 | Ja |
| USA West (Nordkalifornien) | us-west-1 | Ja |
| USA West (Oregon) | us-west-2 | Ja |
| Asien-Pazifik (Mumbai) | ap-south-1 | Ja |
| Asien-Pazifik (Osaka) | ap-northeast-3 | Ja |
| Asien-Pazifik (Seoul) | ap-northeast-2 | Ja |
| Asien-Pazifik (Singapore) | ap-southeast-1 | Ja |
| Asien-Pazifik (Sydney) | ap-southeast-2 | Ja |
| Asien-Pazifik (Tokyo) | ap-northeast-1 | Ja |
| Kanada (Zentral) | ca-central-1 | Ja |
| Europa (Frankfurt) | eu-central-1 | Ja |
| Europa (Ireland) | eu-west-1 | Ja |
| Europa (London) | eu-west-2 | Ja |
| Europa (Paris) | eu-west-3 | Ja |
| Südamerika (São Paulo) | sa-east-1 | Ja |
# Verwenden von serviceverknüpften Rollen mit Amazon EMR für die Write-Ahead-Protokollierung
Amazon EMR verwendet AWS Identity and Access Management (IAM) [serviceverknüpfte](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) Rollen. Eine serviceverknüpfte Rolle ist eine einzigartige Art von IAM-Rolle, die direkt mit Amazon EMR verknüpft ist. Servicebezogene Rollen sind von Amazon EMR vordefiniert und beinhalten alle Berechtigungen, die der Service benötigt, um andere AWS Services in Ihrem Namen aufzurufen.
Serviceverknüpfte Rollen arbeiten mit der Amazon EMR-Servicerolle und dem Amazon EC2 EC2-Instance-Profil für Amazon EMR zusammen. Weitere Informationen über die Service-Rolle und das Instance-Profil finden Sie unter [Konfiguration von IAM-Servicerollen für Amazon EMR-Berechtigungen für AWS Dienste und Ressourcen](emr-iam-roles.md).
Eine serviceverknüpfte Rolle erleichtert die Einrichtung von Amazon EMR, da Sie die erforderlichen Berechtigungen nicht manuell hinzufügen müssen. Amazon EMR definiert die Berechtigungen seiner serviceverknüpften Rollen, und sofern nicht anders definiert, kann nur Amazon EMR seine Rollen übernehmen. Die definierten Berechtigungen umfassen die Vertrauens- und Berechtigungsrichtlinie. Diese Berechtigungsrichtlinie kann keinen anderen IAM-Entitäten zugewiesen werden.
Sie können diese serviceverknüpfte Rolle für Amazon EMR erst löschen, nachdem Sie die zugehörigen Ressourcen gelöscht und alle EMR-Cluster im Konto beendet haben. Dadurch werden Ihre Amazon EMR-Ressourcen geschützt, sodass Sie nicht versehentlich die Zugriffsberechtigung für die Ressourcen entziehen können.
## Servicebezogene Rollenberechtigungen für Write-Ahead Logging (WAL)
Amazon EMR verwendet die serviceverknüpfte Rolle **AWSServiceRoleForEMRWAL**, um einen Cluster-Status abzurufen.
Die serviceverknüpfte AWSService RoleFor EMRWAL-Rolle vertraut darauf, dass die folgenden Dienste die Rolle übernehmen:
+ `emrwal.amazonaws.com`
Die [`EMRDescribeClusterPolicyForEMRWAL`](EMRDescribeClusterPolicyForEMRWAL.md)Berechtigungsrichtlinie für die serviceverknüpfte Rolle ermöglicht es Amazon EMR, die folgenden Aktionen für die angegebenen Ressourcen durchzuführen:
+ Aktion: `DescribeCluster` für `*`
Sie müssen Berechtigungen konfigurieren, damit eine IAM-Entität (in diesem Fall Amazon EMR WAL) eine serviceverknüpfte Rolle erstellen, bearbeiten oder löschen kann. Fügen Sie der Berechtigungsrichtlinie für Ihr Instance-Profil nach Bedarf die folgenden Anweisungen hinzu:
## CreateServiceLinkedRole
**Um einer IAM-Entität zu ermöglichen, die serviceverknüpfte AWSService RoleFor EMRWAL-Rolle zu erstellen**
Fügen Sie die folgende Anweisung der Berechtigungsrichtlinie für die IAM-Entität hinzu, die die serviceverknüpfte Rolle erstellen soll:
```
{
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole",
"iam:PutRolePolicy"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/emrwal.amazonaws.com*/AWSServiceRoleForEMRWAL*",
"Condition": {
"StringLike": {
"iam:AWSServiceName": [
"emrwal.amazonaws.com",
"elasticmapreduce.amazonaws.com.rproxy.govskope.ca.cn"
]
}
}
}
```
## UpdateRoleDescription
**Damit eine IAM-Entität die Beschreibung der serviceverknüpften EMRWAL-Rolle bearbeiten kann AWSService RoleFor**
Fügen Sie die folgende Anweisung der Berechtigungsrichtlinie für die IAM-Entität hinzu, die die Beschreibung einer serviceverknüpften Rolle bearbeiten soll:
```
{
"Effect": "Allow",
"Action": [
"iam:UpdateRoleDescription"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/emrwal.amazonaws.com*/AWSServiceRoleForEMRWAL*",
"Condition": {
"StringLike": {
"iam:AWSServiceName": [
"emrwal.amazonaws.com",
"elasticmapreduce.amazonaws.com.rproxy.govskope.ca.cn"
]
}
}
}
```
## DeleteServiceLinkedRole
**Um einer IAM-Entität zu ermöglichen, die mit dem EMRWAL-Service verknüpfte Rolle zu löschen AWSService RoleFor**
Fügen Sie die folgende Anweisung der Berechtigungsrichtlinie für die IAM-Entität hinzu, die eine serviceverknüpfte Rolle löschen soll:
```
{
"Effect": "Allow",
"Action": [
"iam:DeleteServiceLinkedRole",
"iam:GetServiceLinkedRoleDeletionStatus"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/elasticmapreduce.amazonaws.com*/AWSServiceRoleForEMRCleanup*",
"Condition": {
"StringLike": {
"iam:AWSServiceName": [
"emrwal.amazonaws.com",
"elasticmapreduce.amazonaws.com.rproxy.govskope.ca.cn"
]
}
}
}
```
## Erstellen einer serviceverknüpften Rolle für Amazon EMR
Sie müssen die EMRWAL-Rolle nicht manuell erstellen. AWSService RoleFor Amazon EMR erstellt diese serviceverknüpfte Rolle automatisch, wenn Sie einen WAL-Workspace mit der EMRWAL-CLI oder von dort aus erstellen AWS CloudFormation, oder erstellt die serviceverknüpfte Rolle, wenn Sie einen Workspace für Amazon EMR WAL konfigurieren und die serviceverknüpfte Rolle HBase noch nicht existiert. Sie benötigen die erforderlichen Berechtigungen, um eine serviceverknüpfte Rolle zu erstellen. Anweisungen, mit denen diese Funktion zur Berechtigungsrichtlinie einer IAM-Entität (z. B. eines Benutzers, einer Gruppe oder einer Rolle) hinzugefügt wird, finden Sie beispielsweise im vorherigen Abschnitt. [Servicebezogene Rollenberechtigungen für Write-Ahead Logging (WAL)](#using-service-linked-roles-permissions-wal)
## Bearbeiten einer serviceverknüpften Rolle für Amazon EMR
Amazon EMR erlaubt Ihnen nicht, die mit dem AWSService RoleFor EMRWAL-Service verknüpfte Rolle zu bearbeiten. Nachdem Sie eine serviceverknüpfte Rolle erstellt haben, können Sie den Namen der serviceverknüpften Rolle nicht mehr ändern, da verschiedene Entitäten möglicherweise auf die serviceverknüpfte Rolle verweisen. Sie können die Beschreibung der dienstbezogenen Rolle jedoch mithilfe von IAM bearbeiten.
### Bearbeiten der Beschreibung einer serviceverknüpften Rolle (IAM-Konsole)
Sie können die IAM-Konsole für das Bearbeiten der Beschreibung einer serviceverknüpften Rolle verwenden.
**So bearbeiten Sie die Beschreibung einer serviceverknüpften Rolle (Konsole)**
1. Wählen Sie im Navigationsbereich der IAM Console **Roles** (Rollen) aus.
1. Wählen Sie den Namen der zu ändernden Rolle.
1. Wählen Sie neben **Rollenbeschreibung** rechts **Bearbeiten** aus.
1. Geben Sie eine neue Beschreibung im Dialogfeld ein und wählen Sie **Save changes** (Änderungen speichern).
### Bearbeiten der Beschreibung einer serviceverknüpften Rolle (IAM-CLI)
Sie können IAM-Befehle aus dem verwenden, AWS Command Line Interface um die Beschreibung einer serviceverknüpften Rolle zu bearbeiten.
**So ändern Sie die Beschreibung einer serviceverknüpften Rolle (CLI)**
1. (Optional) Um die aktuelle Beschreibung einer Rolle anzuzeigen, verwenden Sie die folgenden Befehle:
```
$ aws iam get-role --role-name role-name
```
Verwenden Sie den Rollennamen, nicht den ARN, um sich auf Rollen mit den CLI-Befehlen zu beziehen. Wenn eine Rolle zum Beispiel folgenden ARN hat: `arn:aws:iam::123456789012:role/myrole`, verweisen Sie auf die Rolle als **myrole**.
1. Um die Beschreibung einer serviceverknüpften Rolle zu aktualisieren, verwenden Sie einen der folgenden Befehle:
```
$ aws iam update-role-description --role-name role-name --description description
```
### Bearbeiten der Beschreibung einer serviceverknüpften Rolle (IAM-API)
Sie können die IAM-API für das Bearbeiten der Beschreibung einer serviceverknüpften Rolle verwenden.
**So ändern Sie die Beschreibung einer serviceverknüpften Rolle (API)**
1. (Optional) Um die aktuelle Beschreibung einer Rolle anzuzeigen, verwenden Sie den folgenden Befehl:
IAM-API: [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html)
1. Um die Beschreibung einer Rolle zu aktualisieren, verwenden Sie den folgenden Befehl:
IAM-API: [UpdateRoleDescription](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html)
## Löschen einer serviceverknüpften Rolle für Amazon EMR
Wenn Sie eine Funktion oder einen Dienst, für den eine dienstverknüpfte Rolle erforderlich ist, nicht mehr verwenden müssen, empfehlen wir, diese dienstverknüpfte Rolle zu löschen. Auf diese Weise haben Sie keine ungenutzte Entität, die nicht aktiv überwacht oder verwaltet wird. Sie müssen jedoch Ihre serviceverknüpfte Rolle zunächst bereinigen, bevor Sie sie löschen können.
**Anmerkung**
Der Write-Ahead-Protokollierungsvorgang ist nicht betroffen, wenn Sie die AWSService RoleFor EMRWAL-Rolle löschen, aber Amazon EMR löscht die erstellten Protokolle nicht automatisch, sobald Ihr EMR-Cluster beendet wird. Daher müssen Sie die Amazon EMR WAL-Protokolle manuell löschen, wenn Sie die serviceverknüpfte Rolle löschen.
### Bereinigen einer serviceverknüpften Rolle
Bevor Sie mit IAM eine serviceverknüpfte Rolle löschen können, müssen Sie sich zunächst vergewissern, dass die Rolle über keine aktiven Sitzungen verfügt, und alle Ressourcen entfernen, die von der Rolle verwendet werden.
**So überprüfen Sie in der IAM-Konsole, ob die serviceverknüpfte Rolle über eine aktive Sitzung verfügt**
1. Öffnen Sie unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) die IAM-Konsole.
1. Wählen Sie im Navigationsbereich **Rollen**. Wählen Sie den Namen (nicht das Kontrollkästchen) der AWSService RoleFor EMRWAL-Rolle aus.
1. Wählen Sie auf der Seite **Summary (Übersicht)** für die ausgewählte Rolle die Option **Access Advisor (Advisor aufrufen)** aus.
1. Überprüfen Sie auf der Registerkarte **Access Advisor (Advisor aufrufen)** die jüngsten Aktivitäten für die serviceverknüpfte Rolle.
**Anmerkung**
Wenn Sie sich nicht sicher sind, ob Amazon EMR die AWSService RoleFor EMRWAL-Rolle verwendet, können Sie versuchen, die serviceverknüpfte Rolle zu löschen. Wenn der Service die Rolle verwendet, schlägt das Löschen fehl und Sie können die Regionen anzeigen, in denen die mit dem Service verknüpfte Rolle verwendet wird. Wenn die dienstverknüpfte Rolle verwendet wird, müssen Sie warten, bis die Sitzung beendet ist, bevor Sie die dienstverknüpfte Rolle löschen können. Die Sitzung für eine serviceverknüpfte Rolle können Sie nicht widerrufen.
**Um Amazon EMR-Ressourcen zu entfernen, die von der AWSService RoleFor EMRWAL verwendet werden**
+ Beenden Sie alle Cluster in Ihrem Konto. Weitere Informationen finden Sie unter [Beenden Sie einen Amazon EMR-Cluster im Status „Start“, „Wird ausgeführt“ oder „Wartend“](UsingEMR_TerminateJobFlow.md).
### Löschen einer serviceverknüpften Rolle (IAM-Konsole)
Sie können die IAM-Konsole für das Löschen einer serviceverknüpften Rolle verwenden.
**So löschen Sie eine serviceverknüpfte Rolle (Konsole)**
1. Öffnen Sie unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) die IAM-Konsole.
1. Wählen Sie im Navigationsbereich **Rollen**. Aktivieren Sie das Kontrollkästchen neben AWSService RoleFor EMRWAL, nicht den Namen oder die Zeile selbst.
1. Wählen Sie für **Role actions** oben auf der Seite **Delete role** aus.
1. Überprüfen Sie im Bestätigungsdialogfeld die Daten, auf die der Dienst zuletzt zugegriffen hat. Aus diesen Daten geht hervor, wann jede der ausgewählten Rollen zuletzt auf einen AWS Dienst zugegriffen hat. Auf diese Weise können Sie leichter bestätigen, ob die Rolle derzeit aktiv ist. Wählen Sie **Yes, Delete**, um fortzufahren.
1. Sehen Sie sich die Benachrichtigungen in der IAM-Konsole an, um den Fortschritt der Löschung der serviceverknüpften Rolle zu überwachen. Da die Löschung der serviceverknüpften IAM-Rolle asynchron erfolgt, kann die Löschung nach dem Übermitteln der Rolle für die Löschung erfolgreich sein oder fehlschlagen. Wenn der Vorgang fehlschlägt, können Sie in den Benachrichtigungen **View details** oder **View Resources** auswählen, um zu erfahren, warum die Löschung fehlgeschlagen ist. Wenn das Löschen fehlschlägt, weil der Service Ressourcen enthält, die von der Rolle verwendet werden, enthält die Angabe des Fehlergrundes eine Liste der Ressourcen.
### Löschen einer serviceverknüpften Rolle (IAM-CLI)
Sie können IAM-Befehle von verwenden, AWS Command Line Interface um eine dienstverknüpfte Rolle zu löschen. Da eine serviceverknüpfte Rolle nicht gelöscht werden kann, wenn sie verwendet wird oder ihr Ressourcen zugeordnet sind, müssen Sie eine Löschungsanforderung übermitteln. Wenn diese Bedingungen nicht erfüllt sind, kann diese Anforderung verweigert werden.
**So löschen Sie eine serviceverknüpfte Rolle (CLI)**
1. Sie benötigen die `deletion-task-id` aus der Antwort, um den Status der Löschaufgabe zu überprüfen. Geben Sie den folgenden Befehl ein, um eine Löschanforderung für eine serviceverknüpfte Rolle zu übermitteln:
```
$ aws iam [delete-service-linked-role](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-service-linked-role.html) --role-name AWSServiceRoleForEMRWAL
```
1. Geben Sie den folgenden Befehl ein, um den Status der Löschaufgabe zu überprüfen:
```
$ aws iam [get-service-linked-role-deletion-status](https://docs.aws.amazon.com/cli/latest/reference/iam/get-service-linked-role-deletion-status.html) --deletion-task-id deletion-task-id
```
Der Status der Löschaufgabe kann `NOT_STARTED`, `IN_PROGRESS`, `SUCCEEDED` oder `FAILED` lauten. Wenn die Löschung fehlschlägt, gibt der Aufruf den Grund zurück, sodass Sie das Problem beheben können.
### Löschen einer serviceverknüpften Rolle (IAM-API)
Sie können die IAM-API zum Löschen einer serviceverknüpften Rolle verwenden. Da eine serviceverknüpfte Rolle nicht gelöscht werden kann, wenn sie verwendet wird oder ihr Ressourcen zugeordnet sind, müssen Sie eine Löschungsanforderung übermitteln. Wenn diese Bedingungen nicht erfüllt sind, kann diese Anforderung verweigert werden.
**So löschen Sie eine serviceverknüpfte Rolle (API)**
1. Rufen Sie an, um eine Löschanfrage für eine dienstverknüpfte Rolle einzureichen. [DeleteServiceLinkedRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteServiceLinkedRole.html) Geben Sie in der Anfrage den AWSService RoleFor EMRWAL-Rollennamen an.
Sie benötigen die `DeletionTaskId` aus der Antwort, um den Status der Löschaufgabe zu überprüfen.
1. Um den Status der Löschung zu überprüfen, rufen Sie [GetServiceLinkedRoleDeletionStatus](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetServiceLinkedRoleDeletionStatus.html) auf. Geben Sie in der Anforderung die `DeletionTaskId` an.
Der Status der Löschaufgabe kann `NOT_STARTED`, `IN_PROGRESS`, `SUCCEEDED` oder `FAILED` lauten. Wenn die Löschung fehlschlägt, gibt der Aufruf den Grund zurück, sodass Sie das Problem beheben können.
## Unterstützte Regionen für EMRWAL AWSService RoleFor
Amazon EMR unterstützt die Verwendung der serviceverknüpften AWSService RoleFor EMRWAL-Rolle in den folgenden Regionen.
****
| Name der Region | Regions-ID | Amazon EMR Support |
| --- | --- | --- |
| USA Ost (Nord-Virginia) | us-east-1 | Ja |
| USA Ost (Ohio) | us-east-2 | Ja |
| USA West (Nordkalifornien) | us-west-1 | Ja |
| USA West (Oregon) | us-west-2 | Ja |
| Asien-Pazifik (Mumbai) | ap-south-1 | Ja |
| Asien-Pazifik (Singapore) | ap-southeast-1 | Ja |
| Asien-Pazifik (Sydney) | ap-southeast-2 | Ja |
| Asien-Pazifik (Tokyo) | ap-northeast-1 | Ja |
| Europa (Frankfurt) | eu-central-1 | Ja |
| Europa (Ireland) | eu-west-1 | Ja |
# Passen Sie IAM-Rollen mit Amazon EMR an
Sie können die IAM-Servicerollen und -Berechtigungen anpassen, um Rechte entsprechend Ihren Sicherheitsanforderungen zu beschränken. Zum Anpassen von Berechtigungen empfehlen wir, dass Sie neue Rollen und Richtlinien erstellen. Beginnen Sie mit den Berechtigungen in den verwalteten Richtlinien für die Standardrollen (beispielsweise `AmazonElasticMapReduceforEC2Role` und `AmazonElasticMapReduceRole`). Kopieren Sie anschließend die Inhalte in die neuen Richtlinienanweisungen, modifizieren Sie die Berechtigungen entsprechend und fügen Sie die geänderten Richtlinien zu den von Ihnen erstellten Rollen hinzu. Sie müssen über die entsprechenden IAM-Berechtigungen für die Arbeit mit Rollen und Richtlinien verfügen. Weitere Informationen finden Sie unter [Benutzern und Gruppen gestatten, Rollen zu erstellen und zu ändern](emr-iam-roles-create-permissions.md).
Wenn Sie eine benutzerdefinierte EMR-Rolle für EC2 erstellen, folgen Sie dem grundlegenden Workflow, der automatisch ein Instance-Profil mit demselben Namen erstellt. Amazon EC2 ermöglicht es Ihnen, Instance-Profile und Rollen mit unterschiedlichen Namen zu erstellen, aber Amazon EMR unterstützt diese Konfiguration nicht und führt zu einem Fehler „Ungültiges Instance-Profil“, wenn Sie den Cluster erstellen.
**Wichtig**
Eingebundene Richtlinien werden nicht automatisch aktualisiert, wenn sich Serviceanforderungen ändern. Beachten Sie beim Erstellen und Anhängen von Inline-Richtlinien, dass es zu Serviceaktualisierungen kommen kann, die plötzlich zu Berechtigungsfehlern führen. Weitere Informationen hierzu finden Sie unter [Verwaltete Richtlinien und eingebundene Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/policies_managed-vs-inline.html) im *IAM-Benutzerhandbuch* und [Angabe benutzerdefinierter IAM-Rollen beim Erstellen eines Clusters](#emr-iam-roles-launch-jobflow).
Weitere Informationen über die Arbeit mit IAM-Rollen finden Sie in den folgenden Themen im *IAM-Benutzerhandbuch*:
+ [Eine Rolle erstellen, um Berechtigungen an einen Service zu delegieren AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)
+ [Ändern einer Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/modifying-role.html)
+ [Löschen einer Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/deleting-roles.html)
## Angabe benutzerdefinierter IAM-Rollen beim Erstellen eines Clusters
Sie geben die Servicerolle für Amazon EMR und die Rolle für das Amazon-EC2-Instance-Profil an, wenn Sie einen Cluster erstellen. Der Benutzer, der Cluster erstellt, benötigt Berechtigungen, um Rollen abzurufen und sie Amazon EMR und den EC2-Instances zuzuweisen. Andernfalls tritt der Fehler **Benutzerkonto ist nicht zum Aufruf von EC2 autorisiert** auf. Weitere Informationen finden Sie unter [Benutzern und Gruppen gestatten, Rollen zu erstellen und zu ändern](emr-iam-roles-create-permissions.md).
### Mit der Konsole benutzerdefinierte Rollen angeben
Beim Erstellen eines Clusters können Sie eine benutzerdefinierte Servicerolle für Amazon EMR, eine benutzerdefinierte Rolle für das EC2-Instance-Profil und eine benutzerdefinierte Auto-Scaling-Rolle in **Erweiterte Optionen** angeben. Wenn Sie **Quick options (Schnelloptionen)** verwenden, werden die Service-Standardrolle und die Standardrolle für das EC2-Instance-Profil angegeben. Weitere Informationen finden Sie unter [Von Amazon EMR verwendete IAM-Servicerollen](emr-iam-service-roles.md).
------
#### [ Console ]
**Um benutzerdefinierte IAM-Rollen mit der Konsole anzugeben**
Wenn Sie mit der Konsole einen Cluster erstellen, müssen Sie eine benutzerdefinierte Servicerolle für Amazon EMR und eine benutzerdefinierte Rolle für das EC2-Instance-Profil angeben. Weitere Informationen finden Sie unter [Von Amazon EMR verwendete IAM-Servicerollen](emr-iam-service-roles.md).
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon EMR-Konsole unter [https://console.aws.amazon.com/emr](https://console.aws.amazon.com/emr).
1. Wählen Sie im linken Navigationsbereich unter **EMR in EC2** die Option **Cluster** und dann **Cluster erstellen** aus.
1. Suchen Sie unter **Sicherheitskonfiguration und Berechtigungen** die Felder **IAM-Rolle für Instance-Profil** und **Servicerolle für Amazon EMR.** Wählen Sie für jeden Rollentyp eine Rolle aus der Liste aus. Nur Rollen innerhalb Ihres Kontos, die die entsprechende Vertrauensstellungen für diesen Rollentyp besitzen, sind aufgeführt.
1. Wählen Sie alle anderen Optionen aus, die für Ihren Cluster gelten.
1. Um Ihren Cluster jetzt zu starten, wählen Sie **Cluster erstellen** aus.
------
### Verwenden Sie die, AWS CLI um benutzerdefinierte Rollen anzugeben
Sie können eine Servicerolle für Amazon EMR und eine `create-cluster` Servicerolle für EC2 Instance Cluster explizit mithilfe von Optionen mit dem -Befehl in der AWS CLI angeben. Verwenden Sie die Option `--service-role`, um die Servicerolle anzugeben. Verwenden Sie das Argument `InstanceProfile` der Option `--ec2-attributes`, um die Rolle für das EC2-Instance-Profil anzugeben.
Die Auto Scaling-Rolle wird einer separaten Option angegeben, `--auto-scaling-role`. Weitere Informationen finden Sie unter [Verwenden der automatischen Skalierung mit einer benutzerdefinierten Richtlinie für Instanzgruppen in Amazon EMR](emr-automatic-scaling.md).
**Um benutzerdefinierte IAM-Rollen anzugeben, verwenden Sie AWS CLI**
+ Der folgende Befehl gibt die benutzerdefinierte Servicerolle an, *MyCustomServiceRoleForEMR*, und eine benutzerdefinierte Rolle für das EC2-Instance-Profil, *MyCustomServiceRoleForClusterEC2Instances*, wenn Sie einen Cluster starten. Dieses Beispiel verwendet die Amazon-EMR-Standardrolle.
**Anmerkung**
Linux-Zeilenfortsetzungszeichen (\$1) sind aus Gründen der Lesbarkeit enthalten. Sie können entfernt oder in Linux-Befehlen verwendet werden. Entfernen Sie sie unter Windows oder ersetzen Sie sie durch ein Caret-Zeichen (^).
```
aws emr create-cluster --name "Test cluster" --release-label emr-7.12.0 \
--applications Name=Hive Name=Pig --service-role MyCustomServiceRoleForEMR \
--ec2-attributes InstanceProfile=MyCustomServiceRoleForClusterEC2Instances,\
KeyName=myKey --instance-type m5.xlarge --instance-count 3
```
Sie können diese Optionen verwenden, um Standardrollen explizit anzugeben, statt die Option `--use-default-roles` zu verwenden. Die `--use-default-roles`-Option gibt die Servicerolle an sowie die Rolle für das EC2-Instance-Profil, das in der `config`-Datei für die AWS CLI definiert ist.
Das folgende Beispiel zeigt den Inhalt einer `config` Datei für AWS CLI die spezifizierten benutzerdefinierten Rollen für Amazon EMR. Mit dieser Konfigurationsdatei wird der Cluster, wenn die `--use-default-roles`-Option angegeben ist, mit dem *MyCustomServiceRoleForEMR* und *MyCustomServiceRoleForClusterEC2Instances* erstellt. Standardmäßig gibt die `config`-Datei die standardmäßige `service_role` als `AmazonElasticMapReduceRole` und das standardmäßige `instance_profile` als `EMR_EC2_DefaultRole` an.
```
[default]
output = json
region = us-west-1
aws_access_key_id = myAccessKeyID
aws_secret_access_key = mySecretAccessKey
emr =
service_role = MyCustomServiceRoleForEMR
instance_profile = MyCustomServiceRoleForClusterEC2Instances
```
# Konfigurieren von IAM-Rollen für EMRFS-Anforderungen an Amazon S3
**Anmerkung**
Die auf dieser Seite beschriebene EMRFS-Rollenzuordnungsfunktion wurde mit der Einführung von Amazon S3 Access Grants in Amazon EMR 6.15.0 verbessert. Für eine skalierbare Zugriffskontrolllösung für Ihre Daten in Amazon S3 empfehlen wir, [S3 Access Grants mit Amazon EMR](emr-access-grants.md) zu verwenden.
Wenn eine Anwendung, die auf einem -Cluster ausgeführt wird, auf Daten mithilfe des `s3://mydata`-Formats verweist, wird EMRFS von Amazon EMR verwendet, um die Anforderung zu stellen. Für die Interaktion mit Amazon S3 geht EMRFS von den Berechtigungsrichtlinien aus, die mit Ihrem [Amazon-EC2-Instance-Profil](emr-iam-role-for-ec2.md) verknüpft sind. Es wird dasselbe Amazon-EC2-Instance-Profil verwendet, unabhängig vom Benutzer oder der Gruppe, die die Anwendung ausführt, oder vom Speicherort der Daten in Amazon S3.
Wenn Sie Cluster mit mehreren Benutzern haben, die unterschiedliche Zugriffsebenen auf Daten in Amazon S3 über EMRFS benötigen, können Sie eine Sicherheitskonfiguration mit IAM-Rollen für EMRFS einrichten. EMRFS kann eine andere Servicerolle für EC2-Instance-Cluster übernehmen, basierend auf dem Benutzer oder der Gruppe, der bzw. die die Anforderung stellt, oder vom Speicherort der Daten in Amazon S3. Jede IAM-Rolle für EMRFS kann andere Berechtigungen für den Zugriff auf Daten in Amazon S3 besitzen. Weitere Informationen zur Servicerolle für Cluster-EC2-Instances finden Sie unter [Servicerolle für EC2-Cluster-Instances (EC2-Instance-Profil)](emr-iam-role-for-ec2.md).
Die Verwendung benutzerdefinierter IAM-Rollen für EMRFS wird in Amazon-EMR-Versionen 5.10.0 und höher unterstützt. Wenn Sie eine ältere Version verwenden oder zusätzliche Berechtigungsanforderungen haben, die über das, was IAM-Rollen für EMRFS bieten, hinausgehen, können Sie stattdessen einen benutzerdefinierten Anmeldeinformationsanbieter erstellen. Weitere Informationen finden Sie unter [Autorisieren des Zugriffs auf die EMRFS Daten in Amazon S3](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-plan-credentialsprovider).
Wenn Sie eine Sicherheitskonfiguration nutzen, um IAM-Rollen für EMRFS anzugeben, richten Sie Rollenzuordnungen ein. Jede Rollenzuordnung gibt eine IAM-Rolle an, die Kennungen entspricht. Diese Kennungen bestimmen die Basis für den Zugriff auf Amazon S3 über EMRFS. Die Kennungen können Benutzer, Gruppen oder Amazon-S3-Präfixe sein, die einen Datenspeicherort angeben. Wenn EMRFS eine Anforderung an Amazon S3 stellt und die die Anfrage den Grundlagen für den Zugriff entspricht, sorgt EMRFS dafür, dass EC2-Cluster-Instances die entsprechende IAM-Rolle für die Anfrage übernehmen. Die mit dieser Rolle verknüpften IAM-Berechtigungen gelten anstelle der IAM-Berechtigungen, die der Servicerolle für Cluster-EC2-Instances zugewiesen sind.
Die Benutzer und Gruppen in einer Rollenzuordnung sind Hadoop-Benutzer und -gruppen, die auf dem Cluster definiert sind. Benutzer und Gruppen werden EMRFS im Kontext der Anwendung übergeben, die es verwendet (z. B. YARN-Benutzer-Identitätswechsel). Das Amazon-S3-Präfix kann ein Bucket-Spezifizierer beliebiger Tiefe sein (z. B. `s3://amzn-s3-demo-bucket` oder `s3://amzn-s3-demo-bucket/myproject/mydata`). Sie können mehrere Kennungen in einer einzigen Rollenzuordnung angeben, die jedoch alle vom selben Typ sein müssen.
**Wichtig**
IAM-Rollen für EMRFS bieten die Isolierung auf Anwendungsebene zwischen Benutzern der Anwendung. Sie bieten keine Isolierung auf Host-Ebene zwischen Benutzern auf dem Host. Jeder Benutzer mit Zugriff auf das Cluster kann die Isolation umgehen, um eine Rolle zu übernehmen.
Wenn eine Cluster-Anwendung über EMRFS eine Anforderung an Amazon S3 stellt, wertet EMRFS Rollenzuordnungen in der Reihenfolge von oben nach unten aus, in der sie in der Sicherheitskonfiguration erscheinen. Wenn eine über EMRFS gestellte Anforderung nicht mit einer Kennung übereinstimmt, verwendet EMRFS die Servicerolle für Cluster-EC2-Instances. Aus diesem Grund empfehlen wir, dass Sie die Richtlinien, die dieser Rolle zugeordnet werden, auf Berechtigungen in Amazon S3 begrenzen. Weitere Informationen finden Sie unter [Servicerolle für EC2-Cluster-Instances (EC2-Instance-Profil)](emr-iam-role-for-ec2.md).
## Konfigurieren von -Rollen
Bevor Sie eine Sicherheitskonfiguration mit IAM-Rollen für EMRFS einrichten, müssen Sie die Rollen und die Berechtigungsrichtlinien für die Rollen planen und erstellen. Weitere Informationen finden Sie unter [Wie funktionieren IAM Rollen für EC2-Instances?](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html) im *IAM-Benutzerhandbuch*. Wenn Sie Berechtigungsrichtlinien erstellen, empfehlen wir, dass Sie mit der verwalteten Richtlinie beginnen, die der Standard-Amazon-EMR-Rolle für EC2 zugeordnet ist. Bearbeiten Sie diese Richtlinien dann entsprechend Ihren Anforderungen. Der standardmäßige Rollename ist `EMR_EC2_DefaultRole`, und die zu bearbeitende verwaltete Standardrichtlinie ist `AmazonElasticMapReduceforEC2Role`. Weitere Informationen finden Sie unter [Servicerolle für EC2-Cluster-Instances (EC2-Instance-Profil)](emr-iam-role-for-ec2.md).
### Aktualisieren von Vertrauensrichtlinien, um Rollenberechtigungen zu übernehmen
Jede Rolle, die EMRFS verwendet, muss über eine Vertrauensrichtlinie verfügen, die es der Amazon-EMR-Rolle für EC2 des Clusters erlaubt, diese zu übernehmen. Entsprechend muss die Amazon-EMR-Rolle des Clusters für EC2 über eine Vertrauensrichtlinie verfügen, die EMRFS-Rollen deren Übernahme erlaubt.
Das folgende Beispiel einer Vertrauensrichtlinie ist den Rollen für EMRFS zugeordnet. Mit der Anweisung kann die standardmäßige Amazon-EMR-Rolle für EC2 die Rolle übernehmen. Beispiel: Sie verfügen über die zwei fiktiven EMRFS-Rollen `EMRFSRole_First` und `EMRFSRole_Second`. In diesem Fall wird diese Richtlinienanweisung den Vertrauensrichtlinien für jede davon hinzugefügt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": "arn:aws:iam::123456789012:role/EMR_EC2_DefaultRole",
"Sid": "AllowSTSAssumerole"
}
]
}
```
------
Außerdem wird im folgenden Beispiel die Vertrauensrichtlinienanweisung der `EMR_EC2_DefaultRole` hinzugefügt, um zu erlauben, dass die beiden fiktiven EMRFS-Rollen diese übernehmen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": [
"arn:aws:iam::123456789012:role/EMRFSRole_First",
"arn:aws:iam::123456789012:role/EMRFSRole_Second"
],
"Sid": "AllowSTSAssumerole"
}
]
}
```
------
**So aktualisieren Sie die Vertrauensrichtlinie einer IAM-Rolle**
Öffnen Sie unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) die IAM-Konsole.
1. Wählen Sie **Roles (Rollen)**, geben Sie den Namen der Rolle unter **Search (Suche)** ein und wählen Sie dann **Role name (Rollenname)** aus.
1. Wählen Sie auf der Registerkarte **Trust Relationships (Vertrauensbeziehungen)** **Edit Trust Relationship (Vertrauensbeziehung bearbeiten)** aus.
1. Fügen Sie eine Vertrauensanweisung gemäß dem **Richtliniendokument** und den Richtlinien oben hinzu und wählen Sie dann **Vertrauensrichtlinie updaten**.
### Angeben einer Rolle als Schlüsselbenutzer
Wenn eine Rolle den Zugriff auf einen Speicherort in Amazon S3 zulässt, der mit einem AWS KMS key verschlüsselt ist, muss die Rolle als Schlüsselbenutzer angegeben werden. So erhält die Rolle die Berechtigung, den KMS-Schlüssel zu verwenden. Weitere Informationen finden Sie unter [Schlüsselrichtlinien in AWS KMS](https://docs.aws.amazon.com//kms/latest/developerguide/key-policies.html#key-policy-default-allow-users) im *Entwicklerhandbuch für AWS Key Management Service *.
## Einrichten einer Sicherheitskonfiguration mit IAM-Rollen für EMRFS
**Wichtig**
Kann keine der IAM-Rollen für EMRFS, die Sie angeben, angewendet werden, verwendet EMRFS die Amazon-EMR-Rolle für EC2. Sie sollten die Berechtigungen dieser Rolle auf Amazon S3 einschränken wie für Ihre Anwendung erforderlich, und dann diese benutzerdefinierte Rolle anstelle von `EMR_EC2_DefaultRole` angeben, wenn Sie einen Cluster erstellen. Weitere Informationen erhalten Sie unter [Passen Sie IAM-Rollen mit Amazon EMR an](emr-iam-roles-custom.md) und [Angabe benutzerdefinierter IAM-Rollen beim Erstellen eines Clusters](emr-iam-roles-custom.md#emr-iam-roles-launch-jobflow).
**So geben Sie IAM-Rollen für EMRFS-Anforderungen an Amazon S3 mithilfe der Konsole an**
1. Erstellen Sie eine Sicherheitskonfiguration, die Rollenzuordnungen spezifiziert:
1. Wählen Sie in der Amazon-EMR-Konsole die Optionen **Sicherheitskonfigurationen** und **Erstellen** aus.
1. Geben Sie in **Name (Name)** einen Namen für die Sicherheitskonfiguration ein. Verwenden Sie diesen Namen zum Angeben der Sicherheitskonfiguration, wenn Sie einen Cluster erstellen.
1. Wählen Sie **IAM-Rollen für EMRFS-Anforderungen an Amazon S3 verwenden** aus.
1. Wählen Sie eine anzuwendende **IAM-Rolle** aus. Wählen Sie zudem unter **Grundlage für Zugriff** einen ID-Typ (**Benutzer**, **Gruppen** oder **S3-Präfixen**) aus der Liste aus und geben Sie die entsprechenden Kennungen ein. Wenn Sie mehrere Kennungen verwenden, trennen Sie diese durch Komma (ohne Leerzeichen dazwischen) voneinander ab. Weitere Informationen zu den einzelnen ID-Typen finden Sie unten in der [JSON configuration reference](#emrfs-seccfg-json).
1. Wählen Sie **Add role (Rolle hinzufügen)** aus, um zusätzliche Rollenzuordnungen einzurichten wie im vorherigen Schritt beschrieben.
1. Richten Sie weitere Sicherheitskonfigurationsoptionen ein wie erforderlich. Wählen Sie **Create (Erstellen)** aus. Weitere Informationen finden Sie unter [Erstellen Sie eine Sicherheitskonfiguration mit der Amazon EMR-Konsole oder mit AWS CLI](emr-create-security-configuration.md).
1. Geben Sie die Sicherheitskonfiguration an, die Sie oben erstellt haben, wenn Sie einen Cluster erstellen. Weitere Informationen finden Sie unter [Geben Sie eine Sicherheitskonfiguration für einen Amazon EMR-Cluster an](emr-specify-security-configuration.md).
**Um IAM-Rollen für EMRFS-Anfragen an Amazon S3 anzugeben, verwenden Sie den AWS CLI**
1. Verwenden Sie den Befehl `aws emr create-security-configuration`. Dadurch wie ein Name für die Sicherheitskonfiguration spezifiziert sowie die Sicherheitskonfigurationsdetails im JSON-Format.
Der unten gezeigte Beispielbefehl erstellt eine Sicherheitskonfiguration namens `EMRFS_Roles_Security_Configuration`. Diese basiert auf einer JSON-Struktur aus der Datei `MyEmrfsSecConfig.json`, die in demselben Verzeichnis gespeichert ist, in dem der Befehl ausgeführt wird.
```
aws emr create-security-configuration --name EMRFS_Roles_Security_Configuration --security-configuration file://MyEmrFsSecConfig.json.
```
Verwenden Sie die folgenden Richtlinien für die Struktur der Datei `MyEmrFsSecConfig.json`. Sie können diese Struktur zusammen mit Strukturen für andere Sicherheitskonfigurationsoptionen angeben. Weitere Informationen finden Sie unter [Erstellen Sie eine Sicherheitskonfiguration mit der Amazon EMR-Konsole oder mit AWS CLI](emr-create-security-configuration.md).
Im Folgenden finden Sie ein JSON-Beispiel für die Angabe benutzerdefinierter IAM-Rollen für EMRFS innerhalb einer Sicherheitskonfiguration. Es zeigt Rollenzuordnungen für die drei verschiedenen Identifier-Typen, gefolgt von einer Parameterreferenz.
```
{
"AuthorizationConfiguration": {
"EmrFsConfiguration": {
"RoleMappings": [{
"Role": "arn:aws:iam::123456789101:role/allow_EMRFS_access_for_user1",
"IdentifierType": "User",
"Identifiers": [ "user1" ]
},{
"Role": "arn:aws:iam::123456789101:role/allow_EMRFS_access_to_demo_s3_buckets",
"IdentifierType": "Prefix",
"Identifiers": [ "s3://amzn-s3-demo-bucket1/","s3://amzn-s3-demo-bucket2/" ]
},{
"Role": "arn:aws:iam::123456789101:role/allow_EMRFS_access_for_AdminGroup",
"IdentifierType": "Group",
"Identifiers": [ "AdminGroup" ]
}]
}
}
}
```
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/emr-emrfs-iam-roles.html)
1. Verwenden Sie den Befehl `aws emr create-cluster`, um einen Cluster einzurichten, und geben Sie die Sicherheitskonfiguration an, die Sie im vorherigen Schritt erstellt haben.
Im folgenden Beispiel wird ein Cluster erstellt, bei dem Standard-Core-Hadoop-Anwendungen installiert sind. Der Cluster verwendet die oben erstellte Sicherheitskonfiguration als `EMRFS_Roles_Security_Configuration` und verwendet außerdem eine benutzerdefinierte Amazon-EMR-Rolle für EC2, `EC2_Role_EMR_Restrict_S3`, die mit dem `InstanceProfile`-Argument des `--ec2-attributes`-Parameters angegeben wird.
**Anmerkung**
Linux-Zeilenfortsetzungszeichen (\$1) sind aus Gründen der Lesbarkeit enthalten. Sie können entfernt oder in Linux-Befehlen verwendet werden. Entfernen Sie sie unter Windows oder ersetzen Sie sie durch ein Caret-Zeichen (^).
```
aws emr create-cluster --name MyEmrFsS3RolesCluster \
--release-label emr-7.12.0 --ec2-attributes InstanceProfile=EC2_Role_EMR_Restrict_S3,KeyName=MyKey \
--instance-type m5.xlarge --instance-count 3 \
--security-configuration EMRFS_Roles_Security_Configuration
```
# Verwenden Sie ressourcenbasierte Richtlinien für den Zugriff von Amazon EMR auf Glue Data Catalog AWS
Wenn Sie AWS Glue in Verbindung mit Hive, Spark oder Presto in Amazon EMR verwenden, unterstützt AWS Glue ressourcenbasierte Richtlinien zur Steuerung des Zugriffs auf Datenkatalogressourcen. Zu diesen Ressourcen gehören Datenbanken, Tabellen, Verbindungen und benutzerdefinierte Funktionen. Weitere Informationen finden Sie unter [Verwenden von ressourcenbasierten Richtlinien für AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/glue-resource-policies.html) im *AWS -Glue-Entwicklerhandbuch*.
Wenn Sie ressourcenbasierte Richtlinien verwenden, um den Zugriff auf AWS Glue von Amazon EMR aus zu beschränken, muss der Principal, den Sie in der Berechtigungsrichtlinie angeben, der Rollen-ARN sein, der dem EC2-Instance-Profil zugeordnet ist, das bei der Erstellung eines Clusters angegeben wird. Für eine ressourcenbasierte Richtlinie, die an einen Katalog angehängt ist, können Sie beispielsweise den Rollen-ARN für die Standarddienstrolle für Cluster-EC2-Instances *EMR\$1EC2\$1DefaultRole* wie folgt angeben: `Principal`
```
arn:aws:iam::acct-id:role/EMR_EC2_DefaultRole
```
Die *acct-id* kann sich von der AWS Glue-Konto-ID unterscheiden. Dies ermöglicht den Zugriff von EMR-Clustern in verschiedenen Konten aus. Sie können mehrere Principals angeben, von denen jeder aus einem anderen Konto stammt.
# Verwenden Sie IAM-Rollen mit Anwendungen, die AWS Dienste direkt aufrufen
Anwendungen, die auf den EC2-Instances eines Clusters ausgeführt werden, können das EC2-Instanzprofil verwenden, um beim Aufrufen von Diensten temporäre Sicherheitsanmeldeinformationen abzurufen. AWS
Die Hadoop-Versionen verfügbar mit Amazon EMR Version 2.3.0 und höher wurden bereits aktualisiert, um IAM-Rollen zu nutzen. Wenn Ihre Anwendung ausschließlich auf der Hadoop-Architektur ausgeführt wird und keinen Dienst direkt aufruft AWS, sollte sie ohne Änderung mit IAM-Rollen funktionieren.
Wenn Ihre Anwendung Dienste AWS direkt aufruft, müssen Sie sie aktualisieren, um die Vorteile der IAM-Rollen nutzen zu können. Dies bedeutet, dass Ihre Anwendung, anstelle die Anmeldeinformationen von `/etc/hadoop/conf/core-site.xml` auf den EC2-Instances im Cluster zu erwerben, jetzt ein SDK verwendet, um mithilfe der IAM-Rollen auf die Ressourcen zuzugreifen oder die EC2-Instance-Metadaten aufzurufen, um die temporären Anmeldeinformationen zu erhalten.
**Um mithilfe eines AWS SDK auf Ressourcen mit IAM-Rollen zuzugreifen**
+ In den folgenden Themen wird gezeigt, wie Sie mehrere der Rollen verwenden AWS SDKs , um mithilfe von IAM-Rollen auf temporäre Anmeldeinformationen zuzugreifen. Jedes Thema beginnt mit einer Anwendungsversion, die keine IAM-Rollen verwendet, und führt Sie anschließend schrittweise durch die Konvertierung der Anwendung, um sie auf die Verwendung der IAM-Rollen vorzubereiten.
+ [Verwenden von IAM-Rollen für Amazon-EC2-Instances mit dem SDK für Java](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/java-dg-roles.html) im *AWS SDK für Java -Entwicklerhandbuch*
+ [Verwenden von IAM-Rollen für Amazon-EC2-Instances mit dem SDK für .NET](https://docs.aws.amazon.com/sdk-for-net/latest/developer-guide/net-dg-roles.html) im *AWS SDK für .NET -Entwicklerhandbuch*
+ [Verwenden von IAM-Rollen für Amazon-EC2-Instances mit dem SDK für PHP](https://docs.aws.amazon.com/sdk-for-php/latest/developer-guide/php-dg-roles.html) im *AWS SDK für PHP -Entwicklerhandbuch*
+ [Verwenden von IAM-Rollen für Amazon-EC2-Instances mit dem SDK für Ruby](https://docs.aws.amazon.com/sdk-for-ruby/latest/developer-guide/ruby-dg-roles.html) im *AWS SDK für Ruby -Entwicklerhandbuch*
**Abrufen von temporären Anmeldeinformationen aus den EC2-Instance-Metadaten**
+ Rufen Sie die folgende URL von einer EC2-Instance aus auf, die mit der angegebenen IAM-Rolle ausgeführt wird. Diese gibt die zugehörigen temporären Sicherheitsanmeldeinformationen (AccessKeyId, SecretAccessKey SessionToken, und Expiration) zurück. Das folgende Beispiel verwendet das Standard-Instance-Profil für Amazon EMR, `EMR_EC2_DefaultRole`.
```
GET http://169.254.169.254/latest/meta-data/iam/security-credentials/EMR_EC2_DefaultRole
```
Weitere Informationen zum Schreiben von Anwendungen, die IAM-Rollen verwenden, finden Sie unter [Anwendungen, die auf Amazon EC2 EC2-Instances ausgeführt werden, Zugriff AWS auf Ressourcen gewähren](https://docs.aws.amazon.com/IAM/latest/UserGuide/role-usecase-ec2app.html).
Weitere Informationen zu temporären Sicherheitsanmeldeinformationen finden Sie unter [Verwenden temporärer Sicherheitsanmeldeinformationen](https://docs.aws.amazon.com/STS/latest/UsingSTS/using-temp-creds.html) im Handbuch *Verwenden temporärer Sicherheitsanmeldeinformationen*.
# Benutzern und Gruppen gestatten, Rollen zu erstellen und zu ändern
IAM-Prinzipale (Benutzer und Gruppen), die Rollen für einen Cluster erstellen, ändern und festlegen, einschließlich Standardrollen, müssen die Berechtigung haben, die folgenden Aktionen durchzuführen. Weitere Informationen zu den einzelnen Aktionen finden Sie unter [Aktionen](https://docs.aws.amazon.com/IAM/latest/APIReference/API_Operations.html) in der *IAM-API-Referenz*.
+ `iam:CreateRole`
+ `iam:PutRolePolicy`
+ `iam:CreateInstanceProfile`
+ `iam:AddRoleToInstanceProfile`
+ `iam:ListRoles`
+ `iam:GetPolicy`
+ `iam:GetInstanceProfile`
+ `iam:GetPolicyVersion`
+ `iam:AttachRolePolicy`
+ `iam:PassRole`
Die Berechtigung `iam:PassRole` gewährt die Erstellung von Clustern. Die restlichen Berechtigungen gewähren die Erstellung von Standardrollen.
Weitere Informationen zum Zuweisen von Berechtigungen in IAM finden Sie unter [Ändern von Berechtigungen für einen IAM-Benutzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html) im *IAM-Benutzerhandbuch*.
# Beispiele für identitätsbasierte Amazon-EMR-Richtlinien
Benutzer und Rollen besitzen standardmäßig keine Berechtigungen zum Erstellen oder Ändern von Amazon-EMR-Ressourcen. Sie können auch keine Aufgaben mit der AWS-Managementkonsole AWS CLI, oder AWS API ausführen. Ein IAM-Administrator muss IAM-Richtlinien erstellen, die Benutzern und Rollen die Berechtigung zum Ausführen bestimmter API-Operationen für die angegebenen Ressourcen gewähren, die diese benötigen. Der Administrator muss diese Richtlinien anschließend den Benutzern oder -Gruppen anfügen, die diese Berechtigungen benötigen.
Informationen dazu, wie Sie unter Verwendung dieser beispielhaften JSON-Richtliniendokumente eine identitätsbasierte IAM-Richtlinie erstellen, finden Sie unter [Erstellen von Richtlinien auf der JSON-Registerkarte](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) im *IAM-Benutzerhandbuch*.
**Topics**
+ [Bewährte Methoden für Richtlinien für Amazon EMR](security_iam_service-with-iam-policy-best-practices.md)
+ [Gewähren der Berechtigung zur Anzeige der eigenen Berechtigungen für Benutzer](security_iam_id-based-policy-examples-view-own-permissions.md)
+ [Verwaltete Richtlinien von Amazon EMR](emr-managed-iam-policies.md)
+ [IAM-Richtlinien für Tag-basierten Zugriff auf Cluster und EMR-Notebooks](emr-fine-grained-cluster-access.md)
+ [Die ModifyInstanceGroup Aktion in Amazon EMR ablehnen](emr-cluster-deny-modifyinstancegroup.md)
+ [Fehlerbehebung für Amazon-EMR-Identität und -Zugriff](security_iam_troubleshoot.md)
# Bewährte Methoden für Richtlinien für Amazon EMR
Identitätsbasierte Richtlinien sind sehr leistungsfähig. Damit wird bestimmt, ob jemand Amazon-EMR-Ressourcen in Ihrem Konto erstellen, löschen oder darauf zugreifen kann. Diese Aktionen können zu Kosten für Ihr Konto führen. AWS Beachten Sie beim Erstellen oder Bearbeiten identitätsbasierter Richtlinien die folgenden Richtlinien und Empfehlungen:
+ **Erste Schritte mit AWS verwalteten Richtlinien** — Um schnell mit der Nutzung von Amazon EMR zu beginnen, geben Sie Ihren Mitarbeitern mithilfe AWS verwalteter Richtlinien die erforderlichen Berechtigungen. Diese Richtlinien sind bereits in Ihrem Konto verfügbar und werden von AWS. Weitere Informationen finden [Sie unter Erste Schritte zur Nutzung von Berechtigungen mit AWS verwalteten Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-use-aws-defined-policies) im *IAM-Benutzerhandbuch* und. [Verwaltete Richtlinien von Amazon EMR](emr-managed-iam-policies.md)
+ **Gewähren Sie die geringstmöglichen Berechtigungen** – Gewähren Sie beim Erstellen benutzerdefinierter Richtlinien nur die Berechtigungen, die zum Ausführen einer Aufgabe erforderlich sind. Beginnen Sie mit einem Mindestsatz von Berechtigungen und gewähren Sie zusätzliche Berechtigungen wie erforderlich. Dies ist sicherer, als mit Berechtigungen zu beginnen, die zu weit gefasst sind, und dann später zu versuchen, sie zu begrenzen. Weitere Informationen finden Sie unter [Gewähren von geringsten Rechten](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) im *IAM-Benutzerhandbuch*.
+ **Aktivieren Sie für sensible Vorgänge MFA** – Fordern Sie von Benutzern die Verwendung von Multi-Faktor-Authentifizierung (MFA), um zusätzliche Sicherheit beim Zugriff auf sensible Ressourcen oder API-Operationen zu bieten. Weitere Informationen finden Sie unter [Verwenden der Multi-Faktor-Authentifizierung (MFA) in AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html) im *IAM-Benutzerhandbuch*.
+ **Verwenden Sie Richtlinienbedingungen, um zusätzliche Sicherheit zu bieten** – Definieren Sie die Bedingungen, unter denen Ihre identitätsbasierten Richtlinien den Zugriff auf eine Ressource zulassen, soweit praktikabel. Beispielsweise können Sie Bedingungen schreiben, die eine Reihe von zulässigen IP-Adressen festlegen, von denen eine Anforderung stammen muss. Sie können auch Bedingungen schreiben, die Anforderungen nur innerhalb eines bestimmten Datums- oder Zeitbereichs zulassen oder die Verwendung von SSL oder MFA fordern. Weitere Informationen finden Sie unter [IAM-JSON-Richtlinienelemente: Bedingung](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) im *IAM-Benutzerhandbuch*.
# Gewähren der Berechtigung zur Anzeige der eigenen Berechtigungen für Benutzer
In diesem Beispiel wird gezeigt, wie Sie eine Richtlinie erstellen, die Benutzern die Berechtigung zum Anzeigen der eingebundenen Richtlinien und verwalteten Richtlinien gewährt, die ihrer Benutzeridentität angefügt sind. Diese Richtlinie umfasst Berechtigungen zum Ausführen dieser Aktion auf der Konsole oder programmgesteuert mithilfe der AWS CLI OR-API. AWS
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUser",
"iam:GetUserPolicy",
"iam:ListAttachedUserPolicies",
"iam:ListGroupsForUser",
"iam:ListUserPolicies"
],
"Resource": [
"arn:aws:iam::*:user/${aws:username}"
]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicy",
"iam:GetPolicyVersion",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListGroups",
"iam:ListPolicies",
"iam:ListPolicyVersions",
"iam:ListUsers"
],
"Resource": [
"*"
]
}
]
}
```
------
# Verwaltete Richtlinien von Amazon EMR
Die einfachste Möglichkeit, Vollzugriff oder Lesezugriff auf benötigte Amazon-EMR-Aktionen zu erteilen, besteht in der Verwendung von IAM-verwalteten Richtlinien für Amazon EMR. Verwaltete Richtlinien haben den Vorteil, automatisch aktualisiert zu werden, wenn sich die Berechtigungsanforderungen ändern. Wenn Sie eingebundene Richtlinien verwenden, können Service-Veränderungen auftreten, die zu Berechtigungsfehlern führen.
Amazon EMR wird bestehende verwaltete Richtlinien (v1-Richtlinien) zugunsten neuer verwalteter Richtlinien (v2-Richtlinien) ablehnen. Die neuen verwalteten Richtlinien wurden detailliert auf bewährte Verfahren abgestimmt. AWS Sobald die bestehenden verwalteten Richtlinien der Version 1 veraltet sind, können Sie diese Richtlinien keinen neuen IAM-Rollen oder -Benutzern mehr zuordnen. Bestehende Rollen und Benutzer, die veraltete Richtlinien verwenden, können diese weiterhin verwenden. Die verwalteten v2-Richtlinien schränken den Zugriff mithilfe von Tags ein. Sie lassen nur bestimmte Amazon-EMR-Aktionen zu und erfordern Cluster-Ressourcen, die mit einem EMR-spezifischen Schlüssel gekennzeichnet sind. Wir empfehlen Ihnen, die Dokumentation sorgfältig zu lesen, bevor Sie die neuen v2-Richtlinien verwenden.
Die v1-Richtlinien werden in der Liste der **Richtlinien** der IAM-Konsole mit einem Warnsymbol daneben als veraltet markiert. Die veralteten Richtlinien werden die folgenden Merkmale aufweisen:
+ Sie werden unverändert für alle gegenwärtig angefügten Benutzer, Gruppen und Rollen funktionsfähig. Alles funktioniert normal.
+ Sie können nicht neuen Benutzern, Gruppen oder Rollen angefügt werden. Wenn Sie eine der Richtlinien von einer gegenwärtigen Entität trennen, können Sie sie nicht wieder anfügen.
+ Nachdem Sie eine v1-Richtlinie von allen aktuellen Entitäten getrennt haben, ist die Richtlinie nicht mehr sichtbar und kann nicht mehr verwendet werden.
In der folgenden Tabelle werden die Änderungen zwischen den aktuellen Richtlinien (v1) und v2-Richtlinien zusammengefasst.
**Von Amazon EMR verwaltete Richtlinienänderungen**
| Richtlinientyp | Richtliniennamen | Zweck der Richtlinie | Änderungen der v2-Richtlinie |
| --- | --- | --- | --- |
| Standard-EMR-Servicerolle und angehängte verwaltete Richtlinie | **Rollenname: EMR\$1 DefaultRole** V1-Richtlinie (wird nicht mehr unterstützt): **AmazonElasticMapReduceRole**(EMR-Servicerolle) V2-Richtlinienname (mit eingeschränktem Geltungsbereich): [`AmazonEMRServicePolicy_v2`](emr-iam-role.md) | Ermöglicht Amazon EMR, in Ihrem Namen andere AWS Services aufzurufen, wenn Ressourcen bereitgestellt und Service-Level-Aktionen ausgeführt werden. Diese Rolle ist für alle Cluster erforderlich. | Die Richtlinie fügt die neue Berechtigung hinzu. `"ec2:DescribeInstanceTypeOfferings"` Dieser API-Vorgang gibt eine Liste von Instance-Typen zurück, die von einer Liste der angegebenen Availability Zones unterstützt werden. |
| Von IAM verwaltete Richtlinie für vollen Amazon EMR-Zugriff durch angehängte Benutzer, Rollen oder Gruppen | V2-Richtlinienname (mit Geltungsbereich): [`AmazonEMRServicePolicy_v2`](emr-managed-policy-fullaccess-v2.md) | Erlaubt Benutzern volle Berechtigungen für EMR-Aktionen. Beinhaltet iam: PassRole Berechtigungen für Ressourcen. | Die Richtlinie setzt voraus, dass Benutzer Benutzer-Tags zu Ressourcen hinzufügen müssen, bevor sie diese Richtlinie verwenden können. Siehe [Taggen von Ressourcen zur Verwendung verwalteter Richtlinien](#manually-tagged-resources). Für die PassRole Aktion iam: muss die PassedToService Bedingung iam: auf den angegebenen Dienst gesetzt sein. Der Zugriff auf Amazon EC2, Amazon S3 und andere Services ist standardmäßig nicht zulässig. Weitere Informationen finden Sie unter [Verwaltete IAM-Richtlinie für vollen Zugriff (verwaltete Standardrichtlinie v2)](emr-managed-policy-fullaccess-v2.md). |
| Von IAM verwaltete Richtlinie für vollständigen EMR-Zugriff durch angehängte Benutzer, Rollen oder Gruppen | V1-Richtlinie (wird veraltet): [`AmazonElasticMapReduceReadOnlyAccess`](emr-managed-policy-readonly.md) V2-Richtlinienname (mit Geltungsbereich): [`AmazonEMRReadOnlyAccessPolicy_v2`](emr-managed-policy-readonly-v2.md) | Ermöglicht Benutzern nur Leseberechtigungen für Amazon-EMR-Aktionen. | Mit Berechtigungen können nur bestimmte schreibgeschützte ElasticMapReduce-Aktionen ausgeführt werden. Der Zugriff auf Amazon S3 ist standardmäßig nicht zulässig. Weitere Informationen finden Sie unter [Verwaltete IAM-Richtlinie für vollen Zugriff (verwaltete Standardrichtlinie v2)](emr-managed-policy-readonly-v2.md) |
| Standard-EMR-Servicerolle und angehängte verwaltete Richtlinie | **Rollenname: EMR\$1 DefaultRole** V1-Richtlinie (wird nicht mehr unterstützt): **AmazonElasticMapReduceRole**(EMR-Servicerolle) V2-Richtlinienname (mit eingeschränktem Geltungsbereich): [`AmazonEMRServicePolicy_v2`](emr-iam-role.md) | Ermöglicht Amazon EMR, in Ihrem Namen andere AWS Services aufzurufen, wenn Ressourcen bereitgestellt und Service-Level-Aktionen ausgeführt werden. Diese Rolle ist für alle Cluster erforderlich. | Die v2-Servicerolle und die v2-Standardrichtlinie ersetzen die veraltete Rolle und Richtlinie. Die Richtlinie setzt voraus, dass Benutzer Benutzer-Tags zu Ressourcen hinzufügen müssen, bevor sie diese Richtlinie verwenden können. Siehe [Taggen von Ressourcen zur Verwendung verwalteter Richtlinien](#manually-tagged-resources). Siehe [Servicerolle für Amazon EMR (EMR-Rolle)](emr-iam-role.md). |
| Servicerolle für EC2-Cluster-Instances (EC2-Instance-Profil) | **Rollenname: EMR\$1 \$1 EC2 DefaultRole** **Veralteter Richtlinienname: Rolle AmazonElasticMapReducefor EC2** | Ermöglicht Anwendungen, die auf einem EMR-Cluster ausgeführt werden, auf andere AWS -Ressourcen wie Amazon S3 zuzugreifen. Wenn Sie beispielsweise Apache-Spark-Aufträge ausführen, die Daten von Amazon S3 verarbeiten, muss die Richtlinie den Zugriff auf solche Ressourcen zulassen. | Sowohl die Standardrolle als auch die Standardrichtlinie werden demnächst veraltet sein. Es gibt keinen Ersatz für die verwaltete AWS Standardrolle oder -richtlinie. Sie müssen eine ressourcen- oder identitätsbasierte Richtlinie bereitstellen. Das bedeutet, dass Anwendungen, die auf einem EMR-Cluster ausgeführt werden, standardmäßig keinen Zugriff auf Amazon S3 oder andere Ressourcen haben, es sei denn, Sie fügen diese manuell zur Richtlinie hinzu. Siehe [Standardrolle und verwaltete Richtlinie](emr-iam-role-for-ec2.md#emr-ec2-role-default). |
| Andere Richtlinien für EC2-Servicerollen | Aktuelle Richtliniennamen: **AmazonElasticMapReduceforAutoScalingRole, AmazonElasticMapReduceEditorsRole, EMRCleanup Amazon-Richtlinie** | Stellt Berechtigungen bereit, die Amazon EMR benötigt, um auf andere AWS Ressourcen zuzugreifen und Aktionen auszuführen, wenn Auto Scaling, Notebooks oder zum Bereinigen von EC2-Ressourcen verwendet werden. | Keine Änderungen für Version 2. |
## Sicherung von iam: PassRole
Die verwalteten Standardrichtlinien von Amazon EMR mit vollen Berechtigungen beinhalten `iam:PassRole`-Sicherheitskonfigurationen, darunter die folgenden:
+ `iam:PassRole`-Berechtigungen nur für bestimmte Amazon-EMR-Standardrollen.
+ `iam:PassedToService`Bedingungen, die es Ihnen ermöglichen, die Richtlinie nur mit bestimmten AWS Diensten zu verwenden, z. B. `elasticmapreduce.amazonaws.com` und`ec2.amazonaws.com`.
Sie können die JSON-Version der [Amazon EMRFull AccessPolicy \$1v2- und Amazon EMRService](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEMRFullAccessPolicy_v2) [Policy\$1v2-Richtlinien in der IAM-Konsole](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEMRServicePolicy_v2) anzeigen. Wir empfehlen, dass Sie neue Cluster mit den verwalteten v2-Richtlinien erstellen.
Wenn Sie benutzerdefinierte Richtlinien erstellen müssen, empfehlen wir ihnen, mit verwalteten Richtlinien zu beginnen und diese entsprechend Ihren Anforderungen zu bearbeiten.
Informationen zum Anfügen von Richtlinien an [-Benutzer (Prinzipale) finden Sie unter Arbeiten mit verwalteten Richtlinien über die AWS-Managementkonsole](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-using.html#policies_using-managed-console) im *IAM-Benutzerhandbuch*.
## Taggen von Ressourcen zur Verwendung verwalteter Richtlinien
**Amazon EMRService Policy\$1v2** und **Amazon EMRFull AccessPolicy \$1v2** hängen vom begrenzten Zugriff auf Ressourcen ab, die Amazon EMR bereitstellt oder verwendet. Der eingeschränkte Umfang wird dadurch erreicht, dass der Zugriff nur auf die Ressourcen beschränkt wird, denen ein vordefiniertes Benutzer-Tag zugeordnet ist. Wenn Sie eine dieser beiden Richtlinien verwenden, müssen Sie bei der Bereitstellung des Clusters das vordefinierte Benutzer-Tag `for-use-with-amazon-emr-managed-policies = true` übergeben. Amazon EMR verbreitet diese Tags automatisch. Darüber hinaus müssen Sie den im folgenden Abschnitt aufgelisteten Ressourcen ein Benutzer-Tag hinzufügen. Wenn Sie die Amazon-EMR-Konsole verwenden, um Ihren Cluster zu starten, finden Sie weitere Informationen unter [Überlegungen zur Verwendung der Amazon-EMR-Konsole zum Starten von Clustern mit verwalteten v2-Richtlinien](#emr-cluster-v2policy-awsconsole-launch).
Um verwaltete Richtlinien zu verwenden, übergeben Sie das Benutzer-Tag `for-use-with-amazon-emr-managed-policies = true`, wenn Sie einen Cluster mit der CLI, dem SDK oder einer anderen Methode bereitstellen.
Wenn Sie das Tag übergeben, leitet Amazon EMR das Tag an die privaten Subnetz-ENI-, EC2-Instance- und EBS-Volumes weiter, die es erstellt. Amazon EMR kennzeichnet auch automatisch Sicherheitsgruppen, die es erstellt. Wenn Sie jedoch möchten, dass Amazon EMR mit einer bestimmten Sicherheitsgruppe gestartet wird, müssen Sie sie taggen. Für Ressourcen, die nicht von Amazon EMR erstellt wurden, müssen Sie diesen Ressourcen Tags hinzufügen. Beispielsweise müssen Sie Amazon EC2-Subnetze, EC2-Sicherheitsgruppen (sofern sie nicht von Amazon EMR erstellt wurden) und VPCs (wenn Amazon EMR Sicherheitsgruppen erstellen soll) kennzeichnen. Um Cluster mit verwalteten v2-Richtlinien zu starten VPCs, müssen Sie diese VPCs mit dem vordefinierten Benutzertag kennzeichnen. Siehe [Überlegungen zur Verwendung der Amazon-EMR-Konsole zum Starten von Clustern mit verwalteten v2-Richtlinien](#emr-cluster-v2policy-awsconsole-launch).
**Weiterverbreitetes benutzerdefiniertes Tagging**
Amazon EMR kennzeichnet Ressourcen, die es mit den Amazon-EMR-Tags erstellt, die Sie bei der Erstellung eines Clusters angeben. Amazon EMR wendet Tags auf die Ressourcen an, die es während der Lebensdauer des Clusters erstellt.
Amazon EMR verbreitet Benutzer-Tags für die folgenden Ressourcen:
+ Privates Subnetz-ENI (elastische Netzwerkschnittstellen für Servicezugriff)
+ EC2-Instances
+ EBS-Volumes
+ EC2-Startvorlage
**Automatisch getaggte Sicherheitsgruppen**
Amazon EMR kennzeichnet EC2-Sicherheitsgruppen, die es erstellt, mit dem Tag, das für verwaltete v2-Richtlinien für Amazon EMR erforderlich ist `for-use-with-amazon-emr-managed-policies`, unabhängig davon, welche Tags Sie im Befehl „Cluster erstellen“ angeben. Für eine Sicherheitsgruppe, die vor der Einführung der verwalteten Richtlinien der Version 2 erstellt wurde, kennzeichnet Amazon EMR die Sicherheitsgruppe nicht automatisch. Wenn Sie verwaltete v2-Richtlinien mit den Standardsicherheitsgruppen verwenden möchten, die bereits im Konto vorhanden sind, müssen Sie die Sicherheitsgruppen manuell mit `for-use-with-amazon-emr-managed-policies = true` taggen.
**Manuell getaggte Clusterressourcen**
Sie müssen einige Cluster-Ressourcen manuell taggen, damit sie über Amazon-EMR-Standardrollen abgerufen werden können.
+ Sie müssen EC2-Sicherheitsgruppen und EC2-Subnetze manuell mit dem von Amazon EMR verwalteten Richtlinien-Tag `for-use-with-amazon-emr-managed-policies` kennzeichnen.
+ Sie müssen eine VPC manuell taggen, wenn Amazon EMR Standardsicherheitsgruppen erstellen soll. EMR versucht, eine Sicherheitsgruppe mit dem spezifischen Tag zu erstellen, falls die Standardsicherheitsgruppe noch nicht existiert.
Amazon EMR kennzeichnet automatisch die folgenden Ressourcen:
+ Von EMR erstellte EC2-Sicherheitsgruppen
Sie müssen die folgenden Ressourcen manuell taggen:
+ EC2-Subnetz
+ EC2-Sicherheitsgruppen
Optional können Sie die folgenden Ressourcen manuell taggen:
+ VPC – nur wenn Sie möchten, dass Amazon EMR Sicherheitsgruppen erstellt
## Überlegungen zur Verwendung der Amazon-EMR-Konsole zum Starten von Clustern mit verwalteten v2-Richtlinien
Sie können Cluster mit verwalteten v2-Richtlinien mithilfe der Amazon-EMR-Konsole bereitstellen. Im Folgenden finden Sie einige Überlegungen, wenn Sie die Konsole zum Starten von Amazon-EMR-Clustern verwenden.
+ Sie müssen das vordefinierte Tag nicht übergeben. Amazon EMR fügt das Tag automatisch hinzu und leitet es an die entsprechenden Komponenten weiter.
+ Bei Komponenten, die manuell markiert werden müssen, versucht die alte Amazon-EMR-Konsole, sie automatisch zu kennzeichnen, sofern Sie über die erforderlichen Berechtigungen zum Taggen von Ressourcen verfügen. Wenn Sie nicht berechtigt sind, Ressourcen zu taggen, oder wenn Sie die Konsole verwenden möchten, bitten Sie Ihren Administrator, diese Ressourcen zu taggen.
+ Sie können Cluster mit verwalteten v2-Richtlinien nur starten, wenn alle Voraussetzungen erfüllt sind.
+ Die alte Amazon-EMR-Konsole zeigt Ihnen, welche Ressourcen (VPC/Subnetze) markiert werden müssen.
# Von IAM verwaltete Richtlinie für vollen Zugriff (verwaltete Standardrichtlinie v2) für Amazon EMR
Die standardmäßigen verwalteten EMR-Richtlinien mit Geltungsbereich v2 gewähren Benutzern bestimmte Zugriffsrechte. Sie benötigen ein vordefiniertes Amazon-EMR-Ressourcen-Tag und `iam:PassRole` Zustandsschlüssel für Ressourcen, die von Amazon EMR verwendet werden, wie z. B. die `Subnet` und die `SecurityGroup`, die Sie zum Starten Ihres Clusters verwenden.
Um alle erforderlichen Aktionen für Amazon EMR zuzulassen, fügen Sie die `AmazonEMRFullAccessPolicy_v2`-verwaltete Richtlinie an. Diese aktualisierte verwaltete Standardrichtlinie ersetzt die [`AmazonElasticMapReduceFullAccess`](emr-managed-policy-fullaccess.md) verwaltete Richtlinie.
`AmazonEMRFullAccessPolicy_v2` hängt vom begrenzten Zugriff auf Ressourcen ab, die Amazon EMR bereitstellt oder nutzt. Wenn Sie diese Richtlinie verwenden, müssen Sie bei der Bereitstellung des Clusters das Benutzer-Tag `for-use-with-amazon-emr-managed-policies = true` übergeben. Amazon EMR verbreitet diese Tags automatisch. Darüber hinaus müssen Sie möglicherweise manuell ein Benutzer-Tag zu bestimmten Ressourcentypen hinzufügen, z. B. EC2-Sicherheitsgruppen, die nicht von Amazon EMR erstellt wurden. Weitere Informationen finden Sie unter [Taggen von Ressourcen zur Verwendung verwalteter Richtlinien](emr-managed-iam-policies.md#manually-tagged-resources).
Die [https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEMRFullAccessPolicy_v2](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEMRFullAccessPolicy_v2)-Richtlinie schützt Ressourcen, indem sie wie folgt vorgeht:
+ Erfordert, dass Ressourcen für die Clustererstellung und den Zugriff auf Amazon EMR mit dem vordefinierten Tag `for-use-with-amazon-emr-managed-policies` für verwaltete Amazon-EMR-Richtlinien gekennzeichnet werden.
+ Beschränkt die `iam:PassRole`-Aktion auf bestimmte Standardrollen und den `iam:PassedToService`-Zugriff auf bestimmte Services.
+ Bietet standardmäßig keinen Zugriff mehr auf Amazon EC2, Amazon S3 und andere Services.
Im Folgenden finden Sie den Inhalt dieser Richtlinie.
**Anmerkung**
Sie können die Richtlinie auch über den Konsolenlink [https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEMRFullAccessPolicy_v2](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEMRFullAccessPolicy_v2) anzeigen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "RunJobFlowExplicitlyWithEMRManagedTag",
"Effect": "Allow",
"Action": [
"elasticmapreduce:RunJobFlow"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/for-use-with-amazon-emr-managed-policies": "true"
}
}
},
{
"Sid": "ElasticMapReduceActions",
"Effect": "Allow",
"Action": [
"elasticmapreduce:AddInstanceFleet",
"elasticmapreduce:AddInstanceGroups",
"elasticmapreduce:AddJobFlowSteps",
"elasticmapreduce:AddTags",
"elasticmapreduce:CancelSteps",
"elasticmapreduce:CreateEditor",
"elasticmapreduce:CreatePersistentAppUI",
"elasticmapreduce:CreateSecurityConfiguration",
"elasticmapreduce:DeleteEditor",
"elasticmapreduce:DeleteSecurityConfiguration",
"elasticmapreduce:DescribeCluster",
"elasticmapreduce:DescribeEditor",
"elasticmapreduce:DescribeJobFlows",
"elasticmapreduce:DescribePersistentAppUI",
"elasticmapreduce:DescribeSecurityConfiguration",
"elasticmapreduce:DescribeStep",
"elasticmapreduce:DescribeReleaseLabel",
"elasticmapreduce:GetBlockPublicAccessConfiguration",
"elasticmapreduce:GetManagedScalingPolicy",
"elasticmapreduce:GetPersistentAppUIPresignedURL",
"elasticmapreduce:GetAutoTerminationPolicy",
"elasticmapreduce:ListBootstrapActions",
"elasticmapreduce:ListClusters",
"elasticmapreduce:ListEditors",
"elasticmapreduce:ListInstanceFleets",
"elasticmapreduce:ListInstanceGroups",
"elasticmapreduce:ListInstances",
"elasticmapreduce:ListSecurityConfigurations",
"elasticmapreduce:ListSteps",
"elasticmapreduce:ListSupportedInstanceTypes",
"elasticmapreduce:ModifyCluster",
"elasticmapreduce:ModifyInstanceFleet",
"elasticmapreduce:ModifyInstanceGroups",
"elasticmapreduce:OpenEditorInConsole",
"elasticmapreduce:PutAutoScalingPolicy",
"elasticmapreduce:PutBlockPublicAccessConfiguration",
"elasticmapreduce:PutManagedScalingPolicy",
"elasticmapreduce:RemoveAutoScalingPolicy",
"elasticmapreduce:RemoveManagedScalingPolicy",
"elasticmapreduce:RemoveTags",
"elasticmapreduce:SetTerminationProtection",
"elasticmapreduce:StartEditor",
"elasticmapreduce:StopEditor",
"elasticmapreduce:TerminateJobFlows",
"elasticmapreduce:ViewEventsFromAllClustersInConsole"
],
"Resource": [
"*"
]
},
{
"Sid": "ViewMetricsInEMRConsole",
"Effect": "Allow",
"Action": [
"cloudwatch:GetMetricStatistics"
],
"Resource": [
"*"
]
},
{
"Sid": "PassRoleForElasticMapReduce",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::*:role/EMR_DefaultRole",
"arn:aws:iam::*:role/EMR_DefaultRole_V2"
],
"Condition": {
"StringLike": {
"iam:PassedToService": "elasticmapreduce.amazonaws.com*"
}
}
},
{
"Sid": "PassRoleForEC2",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::*:role/EMR_EC2_DefaultRole"
],
"Condition": {
"StringLike": {
"iam:PassedToService": "ec2.amazonaws.com*"
}
}
},
{
"Sid": "PassRoleForAutoScaling",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::*:role/EMR_AutoScaling_DefaultRole"
],
"Condition": {
"StringLike": {
"iam:PassedToService": "application-autoscaling.amazonaws.com*"
}
}
},
{
"Sid": "ElasticMapReduceServiceLinkedRole",
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole"
],
"Resource": [
"arn:aws:iam::*:role/aws-service-role/elasticmapreduce.amazonaws.com*/AWSServiceRoleForEMRCleanup*"
],
"Condition": {
"StringEquals": {
"iam:AWSServiceName": [
"elasticmapreduce.amazonaws.com",
"elasticmapreduce.amazonaws.com.rproxy.govskope.ca.cn"
]
}
}
},
{
"Sid": "ConsoleUIActions",
"Effect": "Allow",
"Action": [
"ec2:DescribeAccountAttributes",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeImages",
"ec2:DescribeKeyPairs",
"ec2:DescribeNatGateways",
"ec2:DescribeRouteTables",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"ec2:DescribeVpcEndpoints",
"s3:ListAllMyBuckets",
"iam:ListRoles"
],
"Resource": [
"*"
]
}
]
}
```
------
# Von IAM verwaltete Richtlinie für vollen Zugriff (demnächst veraltet)
Die verwalteten Richtlinien `AmazonElasticMapReduceFullAccess` und `AmazonEMRFullAccessPolicy_v2` AWS Identity and Access Management (IAM) gewähren alle erforderlichen Aktionen für Amazon EMR und andere Services.
**Wichtig**
Die verwaltete Richtlinie `AmazonElasticMapReduceFullAccess` ist veraltet und wird nicht mehr für die Verwendung mit Amazon EMR empfohlen. Nutzen Sie stattdessen [`AmazonEMRFullAccessPolicy_v2`](emr-managed-policy-fullaccess-v2.md). Wenn der IAM-Service die v1-Richtlinie irgendwann als veraltet markiert, können Sie sie keiner Rolle zuordnen. Sie können einem Cluster jedoch eine bestehende Rolle zuordnen, auch wenn diese Rolle die veraltete Richtlinie verwendet.
Die verwalteten Standardrichtlinien von Amazon EMR mit vollen Berechtigungen beinhalten `iam:PassRole`-Sicherheitskonfigurationen, darunter die folgenden:
+ `iam:PassRole`-Berechtigungen nur für bestimmte Amazon-EMR-Standardrollen.
+ `iam:PassedToService`Bedingungen, die es Ihnen ermöglichen, die Richtlinie nur mit bestimmten AWS Diensten wie `elasticmapreduce.amazonaws.com` und zu verwenden. `ec2.amazonaws.com`
Sie können die JSON-Version der [Amazon EMRFull AccessPolicy \$1v2- und Amazon EMRService](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEMRFullAccessPolicy_v2) [Policy\$1v2-Richtlinien in der IAM-Konsole](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEMRServicePolicy_v2) anzeigen. Wir empfehlen, dass Sie neue Cluster mit den verwalteten v2-Richtlinien erstellen.
Sie können den Inhalt der veralteten v1-Richtlinie unter einsehen. AWS-Managementkonsole [https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonElasticMapReduceFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonElasticMapReduceFullAccess) Die `ec2:TerminateInstances`-Aktion in der Richtlinie gewährt einem Benutzer oder einer Rolle die Erlaubnis, eine der Amazon-EC2-Instances zu kündigen, die mit dem IAM-Konto verknüpft sind. Dies schließt Instances ein, die nicht Teil eines EMR-Clusters sind.
# Von IAM verwaltete Richtlinie für schreibgeschützten Zugriff (verwaltete Standardrichtlinie v2) für Amazon EMR
Um Amazon EMR nur Leserechte zu gewähren, fügen Sie die verwaltete **Amazon EMRRead OnlyAccessPolicy \$1v2-Richtlinie** bei. Diese verwaltete Standardrichtlinie ersetzt die [`AmazonElasticMapReduceReadOnlyAccess`](emr-managed-policy-readonly.md) verwaltete Richtlinie. Der Inhalt dieser Richtlinienerklärung wird im folgenden Ausschnitt dargestellt. Im Vergleich zur `AmazonElasticMapReduceReadOnlyAccess`-Richtlinie verwendet die `AmazonEMRReadOnlyAccessPolicy_v2`-Richtlinie keine Platzhalterzeichen für das `elasticmapreduce`-Element. Stattdessen beschränkt sich die standardmäßige v2-Richtlinie auf die zulässigen `elasticmapreduce`-Aktionen.
**Anmerkung**
Sie können den AWS-Managementkonsole Link auch verwenden, um die Richtlinie [https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEMRReadOnlyAccessPolicy_v2](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEMRReadOnlyAccessPolicy_v2)einzusehen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ElasticMapReduceActions",
"Effect": "Allow",
"Action": [
"elasticmapreduce:DescribeCluster",
"elasticmapreduce:DescribeEditor",
"elasticmapreduce:DescribeJobFlows",
"elasticmapreduce:DescribeSecurityConfiguration",
"elasticmapreduce:DescribeStep",
"elasticmapreduce:DescribeReleaseLabel",
"elasticmapreduce:GetBlockPublicAccessConfiguration",
"elasticmapreduce:GetManagedScalingPolicy",
"elasticmapreduce:GetAutoTerminationPolicy",
"elasticmapreduce:ListBootstrapActions",
"elasticmapreduce:ListClusters",
"elasticmapreduce:ListEditors",
"elasticmapreduce:ListInstanceFleets",
"elasticmapreduce:ListInstanceGroups",
"elasticmapreduce:ListInstances",
"elasticmapreduce:ListSecurityConfigurations",
"elasticmapreduce:ListSteps",
"elasticmapreduce:ListSupportedInstanceTypes",
"elasticmapreduce:ViewEventsFromAllClustersInConsole"
],
"Resource": [
"*"
]
},
{
"Sid": "ViewMetricsInEMRConsole",
"Effect": "Allow",
"Action": [
"cloudwatch:GetMetricStatistics"
],
"Resource": [
"*"
]
}
]
}
```
------
# Von IAM verwaltete Richtlinie für vollen Zugriff (demnächst veraltet)
Die `AmazonElasticMapReduceReadOnlyAccess`-verwaltete Richtlinie ist demnächst veraltet. Sie können diese Richtlinie nicht anhängen, wenn Sie neue Cluster starten. `AmazonElasticMapReduceReadOnlyAccess` wurde durch die verwaltete Standardrichtlinie [`AmazonEMRReadOnlyAccessPolicy_v2`](emr-managed-policy-readonly-v2.md) von Amazon EMR ersetzt. Der Inhalt dieser Richtlinienerklärung wird im folgenden Ausschnitt dargestellt. Platzhalterzeichen für das `elasticmapreduce`-Element geben an, dass nur Aktionen, die mit der angegebenen Zeichenfolgen beginnen, zulässig sind. Hinweis: Da diese Richtlinie Aktionen nicht ausdrücklich verweigert, kann dennoch eine andere Richtlinienanweisung verwendet werden, um den Zugriff auf bestimmte Aktionen zu gewähren.
**Anmerkung**
Sie können die Richtlinie auch verwenden AWS-Managementkonsole , um die Richtlinie einzusehen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticmapreduce:Describe*",
"elasticmapreduce:List*",
"elasticmapreduce:ViewEventsFromAllClustersInConsole",
"s3:GetObject",
"s3:ListAllMyBuckets",
"s3:ListBucket",
"sdb:Select",
"cloudwatch:GetMetricStatistics"
],
"Resource": [
"*"
],
"Sid": "AllowELASTICMAPREDUCEDescribe"
}
]
}
```
------
# AWS verwaltete Richtlinie: EMRDescribe ClusterPolicyFor EMRWAL
Sie können `EMRDescribeClusterPolicyForEMRWAL` nicht an Ihre IAM-Entitäten anhängen. Diese Richtlinie ist mit einer dienstbezogenen Rolle verknüpft, die es Amazon EMR ermöglicht, Aktionen in Ihrem Namen durchzuführen. Weitere Informationen zu dieser dienstbezogenen Rolle finden Sie unter. [Verwenden von serviceverknüpften Rollen mit Amazon EMR für die Write-Ahead-Protokollierung](using-service-linked-roles-wal.md)
Diese Richtlinie gewährt Nur-Lese-Berechtigungen, die es dem WAL-Service für Amazon EMR ermöglichen, den Status eines Clusters zu finden und zurückzugeben. Weitere Informationen zu Amazon EMR WAL finden Sie unter [Write-Ahead-Logs (WAL) für](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hbase-wal.html) Amazon EMR.
**Details zu Berechtigungen**
Diese Richtlinie umfasst die folgenden Berechtigungen:
+ `emr`— Ermöglicht Principals, den Cluster-Status von Amazon EMR aus zu beschreiben. Dies ist erforderlich, damit Amazon EMR bestätigen kann, wann ein Cluster beendet wurde, und dann nach dreißig Tagen alle vom Cluster hinterlassenen WAL-Protokolle bereinigen kann.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticmapreduce:DescribeCluster"
],
"Resource": [
"*"
],
"Sid": "AllowELASTICMAPREDUCEDescribecluster"
}
]
}
```
------
## AWS verwaltete Richtlinien für Amazon EMR
Eine AWS verwaltete Richtlinie ist eine eigenständige Richtlinie, die von erstellt und verwaltet AWS wird. AWS Verwaltete Richtlinien dienen dazu, Berechtigungen für viele gängige Anwendungsfälle bereitzustellen, sodass Sie damit beginnen können, Benutzern, Gruppen und Rollen Berechtigungen zuzuweisen.
Beachten Sie, dass AWS verwaltete Richtlinien für Ihre speziellen Anwendungsfälle möglicherweise keine Berechtigungen mit den geringsten Rechten gewähren, da sie allen AWS Kunden zur Verfügung stehen. Wir empfehlen Ihnen, die Berechtigungen weiter zu reduzieren, indem Sie [vom Kunden verwaltete Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) definieren, die speziell auf Ihre Anwendungsfälle zugeschnitten sind.
Sie können die in AWS verwalteten Richtlinien definierten Berechtigungen nicht ändern. Wenn die in einer AWS verwalteten Richtlinie definierten Berechtigungen AWS aktualisiert werden, wirkt sich das Update auf alle Prinzidentitäten (Benutzer, Gruppen und Rollen) aus, denen die Richtlinie zugeordnet ist. AWS aktualisiert eine AWS verwaltete Richtlinie höchstwahrscheinlich, wenn eine neue Richtlinie eingeführt AWS-Service wird oder neue API-Operationen für bestehende Dienste verfügbar werden.
Weitere Informationen finden Sie unter [Von AWS verwaltete Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) im *IAM-Benutzerhandbuch*.
# Amazon EMR-Updates für AWS verwaltete Richtlinien
Sehen Sie sich Details zu Aktualisierungen der AWS verwalteten Richtlinien für Amazon EMR an, seit dieser Service begonnen hat, diese Änderungen zu verfolgen.
| Änderungen | Beschreibung | Datum |
| --- | --- | --- |
| [`AmazonEMRServicePolicy_v2`](emr-iam-role.md) – Aktualisierung auf eine bestehende Richtlinie | Ab Amazon EMR Version 7.5.0 hinzugefügt ec2:CreateVpcEndpoint und für eine optimale Benutzererfahrung ec2:CreateTags erforderlich. ec2:ModifyVpcEndpoint | 4. März 2025 |
| [`AmazonEMRServicePolicy_v2`](emr-iam-role.md) – Aktualisierung auf eine bestehende Richtlinie | Hinzugefügtelasticmapreduce:CreatePersistentAppUI, undelasticmapreduce:DescribePersistentAppUI. elasticmapreduce:GetPersistentAppUIPresignedURL | 28. Februar 2025 |
| [`EMRDescribeClusterPolicyForEMRWAL`](EMRDescribeClusterPolicyForEMRWAL.md) – Neue Richtlinie | Es wurde eine neue Richtlinie hinzugefügt, sodass Amazon EMR dreißig Tage nach Beendigung des Clusters den Clusterstatus für die WAL-Bereinigung bestimmen kann. | 10. August 2023 |
| [`AmazonEMRFullAccessPolicy_v2`](emr-managed-policy-fullaccess-v2.md) und [`AmazonEMRReadOnlyAccessPolicy_v2`](emr-managed-policy-readonly-v2.md) – Zur Aktualisierung einer bestehenden Richtlinie | elasticmapreduce:DescribeReleaseLabel und elasticmapreduce:GetAutoTerminationPolicy hinzugefügt. | 21. April 2022 |
| [`AmazonEMRFullAccessPolicy_v2`](emr-managed-policy-fullaccess-v2.md) – Aktualisierung auf eine bestehende Richtlinie | ec2:DescribeImages hinzugefügt für [Verwendung eines benutzerdefinierten AMI für mehr Flexibilität bei der Amazon EMR-Clusterkonfiguration](emr-custom-ami.md). | 15. Februar 2022 |
| [**Verwaltete Richtlinien von Amazon EMR**](emr-managed-iam-policies.md) | Aktualisiert, um die Verwendung vordefinierter Benutzer-Tags zu verdeutlichen. Es wurde ein Abschnitt zur Verwendung der AWS Konsole zum Starten von Clustern mit verwalteten v2-Richtlinien hinzugefügt. | 29. September 2021 |
| [`AmazonEMRFullAccessPolicy_v2`](emr-managed-policy-fullaccess-v2.md) – Aktualisierung auf eine bestehende Richtlinie | Die Aktionen PassRoleForAutoScaling und PassRoleForEC2 wurden dahingehend geändert, dass der StringLike-Bedingungsoperator entsprechend "iam:PassedToService":"application-autoscaling.amazonaws.com\$1" und "iam:PassedToService":"ec2.amazonaws.com\$1" verwendet wird. | 20. Mai 2021 |
| [`AmazonEMRFullAccessPolicy_v2`](emr-managed-policy-fullaccess-v2.md) – Aktualisierung auf eine bestehende Richtlinie | Ungültige Aktion `s3:ListBuckets` wurde entfernt und durch `s3:ListAllMyBuckets`-Aktion ersetzt. Die Erstellung von serviceverknüpften Rollen (SLR) wurde aktualisiert und ist nun explizit auf die einzige SLR beschränkt, die Amazon EMR mit expliziten Serviceprinzipien hat. Die SLRs , die erstellt werden können, sind genau die gleichen wie vor dieser Änderung. | 23. März 2021 |
| [`AmazonEMRFullAccessPolicy_v2`](emr-managed-policy-fullaccess-v2.md) – Neue Richtlinie | Amazon EMR hat neue Berechtigungen für den Bereichszugriff auf Ressourcen hinzugefügt und eine Voraussetzung hinzugefügt, dass Benutzer Ressourcen vordefinierte Benutzer-Tags hinzufügen müssen, bevor sie von Amazon EMR verwaltete Richtlinien verwenden können. `iam:PassRole`-Aktion erfordert, dass die `iam:PassedToService`-Bedingung auf den angegebenen Service gesetzt ist. Der Zugriff auf Amazon EC2, Amazon S3 und andere Services ist standardmäßig nicht zulässig. | 11. März 2021 |
| [`AmazonEMRServicePolicy_v2`](emr-iam-role.md) – Neue Richtlinie | Fügt die Voraussetzung hinzu, dass Benutzer Benutzer-Tags zu Ressourcen hinzufügen müssen, bevor sie diese Richtlinie verwenden können. | 11. März 2021 |
| [`AmazonEMRReadOnlyAccessPolicy_v2`](emr-managed-policy-readonly-v2.md) – Neue Richtlinie | Mit Berechtigungen können nur bestimmte schreibgeschützte ElasticMapReduce-Aktionen ausgeführt werden. Der Zugriff auf Amazon S3 ist standardmäßig nicht zulässig. | 11. März 2021 |
| Amazon EMR hat mit der Nachverfolgung von Änderungen begonnen | Amazon EMR hat damit begonnen, Änderungen an seinen AWS verwalteten Richtlinien nachzuverfolgen. | 11. März 2021 |
# IAM-Richtlinien für Tag-basierten Zugriff auf Cluster und EMR-Notebooks
Sie können in Ihrer identitätsbasierten Richtlinie auf Tags basierende Bedingungen zum Steuern des Zugriffs auf Cluster und EMR-Notebooks verwenden.
Weitere Informationen zum Hinzufügen von Tags zu Clustern finden Sie unter [Tagging EMR Clusters](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-tags.html).
Die folgenden Beispiele zeigen verschiedene Szenarien und Möglichkeiten zur Nutzung der Bedingungsoperatoren mit Amazon-EMR-Bedingungskontextschlüsseln. Diese IAM-Richtlinienanweisungen dienen nur zu Demonstrationszwecken und sollten nicht in Produktionsumgebungen verwendet werden. Es gibt mehrere Möglichkeiten für die Kombination von Richtlinienanweisungen zum Gewähren oder Verweigern von Berechtigungen entsprechend Ihren Anforderungen. Weitere Informationen zum Planen und Testen von IAM-Richtlinien finden Sie im [IAM-Benutzerhandbuch](https://docs.aws.amazon.com/IAM/latest/UserGuide/).
**Wichtig**
Das explizite Ablehnen von Berechtigungen für Markierungsaktionen stellt eine wichtige Überlegung dar. Dadurch wird verhindert, dass Benutzer eine Ressource markieren und sich dadurch selbst Berechtigungen erteilen, die Sie nicht gewähren wollten. Wenn Sie Tagging-Aktionen für eine Ressource nicht verweigern, kann ein Benutzer Tags ändern und die Absicht der tagbasierten Richtlinien umgehen.
## Beispiel identitätsbasierter Richtlinienanweisungen für Cluster
Die folgenden Beispiele zeigen identitätsbasierte Berechtigungsrichtlinien, die verwendet werden, um die Aktionen zu steuern, die mit EMR-Clustern zulässig sind.
**Wichtig**
Für die `ModifyInstanceGroup`-Aktion in Amazon EMR müssen Sie keine Cluster-ID angeben. Aus diesem Grund sind zusätzliche Überlegungen erforderlich, um diese Aktion auf der Grundlage von Cluster-Tags abzulehnen. Weitere Informationen finden Sie unter [Die ModifyInstanceGroup Aktion in Amazon EMR ablehnen](emr-cluster-deny-modifyinstancegroup.md).
**Topics**
+ [Zulassen von Aktionen nur für Cluster mit bestimmten Tag-Werten](#emr-cluster-access-example-tagvalue)
+ [Erfordert Cluster-Tagging, wenn ein Cluster erstellt wird](#emr-cluster-access-example-require-tagging)
+ [Aktionen für Cluster mit einem bestimmten Tag zulassen, unabhängig vom Tag-Wert](#emr-cluster-access-example-tag)
### Zulassen von Aktionen nur für Cluster mit bestimmten Tag-Werten
Die folgenden Beispiele veranschaulichen eine Richtlinie, mit der ein Benutzer Aktionen auf der Grundlage des Cluster-Tags `department` mit dem Wert `dev` durchführen, sowie Cluster mit demselben Tag markieren kann. Das letzte Richtlinienbeispiel zeigt, wie Sie Rechte zum Markieren von EMR-Clustern mit etwas anderem als demselben Tag ablehnen.
Im folgenden Richtlinienbeispiel versucht der `StringEquals`-Bedingungsoperator, `dev` und den Wert für das Tag `department` abzugleichen. Wenn das Tag `department` dem Cluster nicht hinzugefügt wurde oder den Wert `dev` nicht enthält, ist die Richtlinie nicht anzuwenden und die Aktionen werden von dieser Richtlinie nicht zugelassen. Wenn keine anderen Richtlinienanweisungen die Aktionen zulassen, kann der Benutzer nur mit Clustern arbeiten, die dieses Tag mit diesem Wert enthalten.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Stmt12345678901234",
"Effect": "Allow",
"Action": [
"elasticmapreduce:DescribeCluster",
"elasticmapreduce:ListSteps",
"elasticmapreduce:TerminateJobFlows",
"elasticmapreduce:SetTerminationProtection",
"elasticmapreduce:ListInstances",
"elasticmapreduce:ListInstanceGroups",
"elasticmapreduce:ListBootstrapActions",
"elasticmapreduce:DescribeStep"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/department": "dev"
}
}
}
]
}
```
------
Sie können auch mehrere Tag-Werte mithilfe eines Bedingungsoperators angeben. Um beispielsweise alle Aktionen in Clustern zuzulassen, in denen das Tag `department` den Wert `dev` oder `test` enthält können Sie den Bedingungsblock im vorherigen Beispiel durch Folgendes ersetzen.
```
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/department":["dev", "test"]
}
}
```
### Erfordert Cluster-Tagging, wenn ein Cluster erstellt wird
Wie im oben stehenden Beispiel sucht die folgenden Beispielrichtlinie dasselbe übereinstimmende Tag: den Wert `dev` für das Tag `department`. In diesem Beispiel gibt der `RequestTag`-Bedingungsschlüssel jedoch an, dass die Richtlinie während der Tag-Erstellung gilt. Sie müssen also einen Cluster mit einem Tag erstellen, der dem angegebenen Wert entspricht.
Um einen Cluster mit einem Tag zu erstellen, benötigen Sie auch die Erlaubnis für die `elasticmapredue:AddTags`-Aktion. Bei dieser Anweisung stellt der `elasticmapreduce:ResourceTag`-Bedingungsschlüssel sicher, dass IAM nur Zugriff auf Tag-Ressourcen gewährt, deren Wert `dev` auf dem `department`-Tag steht. Das `Resource`-Element wird verwendet, um diese Berechtigung auf Clusterressourcen zu beschränken.
Für die `PassRole` Ressourcen müssen Sie die AWS Konto-ID oder den Alias, den Namen der Servicerolle in der `PassRoleForEMR` Erklärung und den Namen des Instance-Profils in der `PassRoleForEC2` Erklärung angeben. Weitere Informationen zum IAM-ARN-Format finden Sie unter [IAM ARNs](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-arns) im *IAM-Benutzerhandbuch*.
Weitere Informationen zum Abgleichen von Tag-Schlüsselwerten finden Sie unter [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requesttag](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requesttag) im *IAM-Benutzerhandbuch*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "RunJobFlowExplicitlyWithTag",
"Effect": "Allow",
"Action": [
"elasticmapreduce:RunJobFlow"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/department": "dev"
}
}
},
{
"Sid": "AddTagsForDevClusters",
"Effect": "Allow",
"Action": [
"elasticmapreduce:AddTags"
],
"Resource": [
"arn:aws:elasticmapreduce:*:*:cluster/*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/department": "dev"
}
}
},
{
"Sid": "PassRoleForEMR",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::123456789012:role/Role-Name-With-Path"
],
"Condition": {
"StringLike": {
"iam:PassedToService": "elasticmapreduce.amazonaws.com*"
}
}
},
{
"Sid": "PassRoleForEC2",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::123456789012:role/Role-Name-With-Path"
],
"Condition": {
"StringLike": {
"iam:PassedToService": "ec2.amazonaws.com*"
}
}
}
]
}
```
------
### Aktionen für Cluster mit einem bestimmten Tag zulassen, unabhängig vom Tag-Wert
Sie können auch Aktionen nur für Cluster mit einem bestimmten Tag, unabhängig vom Tag-Wert, zulassen. Dazu können Sie den `Null`-Operator verwenden. Weitere Informationen finden Sie unter [Bedingungsoperator zum Überprüfen der Existenz von Bedingungsschlüsseln](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Conditions_Null) im *IAM-Benutzerhandbuch*. Um beispielsweise Aktionen nur in EMR-Clustern mit dem Tag `department` unabhängig von dem enthaltenen Wert, zuzulassen, können Sie die Bedingungsblöcke im vorherigen Beispiel durch Folgendes ersetzen. Der `Null`-Operator sucht einem vorhandenen `department`-Tag in einem EMR-Cluster. Wenn das Tag vorhanden ist, wird die Anweisung `Null` entsprechend der in dieser Richtlinienanweisung angegebenen Bedingung mit "false" ausgewertet und die jeweiligen Aktionen werden zugelassen.
```
1. "Condition": {
2. "Null": {
3. "elasticmapreduce:ResourceTag/department":"false"
4. }
5. }
```
Mit der folgenden Richtlinienanweisung kann ein Benutzer einen EMR-Cluster nur erstellen, wenn der Cluster über ein `department`-Tag mit einem beliebigen Wert verfügt. Für die `PassRole` Ressource müssen Sie die AWS Konto-ID oder den Alias und den Namen der Servicerolle angeben. Weitere Informationen zum IAM-ARN-Format finden Sie unter [IAM ARNs](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-arns) im *IAM-Benutzerhandbuch*.
Weitere Informationen finden Sie unter [Bedingungsoperator zum Überprüfen der Existenz von Bedingungsschlüsseln](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html#Conditions_Null) im *IAM-Benutzerhandbuch*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "CreateClusterTagNullCondition",
"Effect": "Allow",
"Action": [
"elasticmapreduce:RunJobFlow"
],
"Resource": [
"*"
],
"Condition": {
"Null": {
"aws:RequestTag/department": "false"
}
}
},
{
"Sid": "AddTagsNullCondition",
"Effect": "Allow",
"Action": [
"elasticmapreduce:AddTags"
],
"Resource": [
"arn:aws:elasticmapreduce:*:*:cluster/*"
],
"Condition": {
"Null": {
"elasticmapreduce:ResourceTag/department": "false"
}
}
},
{
"Sid": "PassRoleForElasticMapReduce",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::123456789012:role/Role-Name-With-Path"
],
"Condition": {
"StringLike": {
"iam:PassedToService": "elasticmapreduce.amazonaws.com*"
}
}
},
{
"Sid": "PassRoleForEC2",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::123456789012:role/Role-Name-With-Path"
],
"Condition": {
"StringLike": {
"iam:PassedToService": "ec2.amazonaws.com*"
}
}
}
]
}
```
------
## Beispielhafte identitätsbasierte Richtlinienanweisungen für EMR Notebooks
Die IAM-Beispiel-Richtlinienanweisungen in diesem Abschnitt zeigen häufige Szenarien für die Verwendung von Schlüsseln, um zulässige Aktionen mit EMR Notebooks zu beschränken. Solange keine andere mit dem Prinzipal (Benutzer) verknüpfte Richtlinie die Aktionen zulässt, schränken die Bedingungskontextschlüssel die zulässigen Aktionen wie angegeben ein.
**Example – Erlaubt nur den Zugriff auf EMR Notebooks, die ein Benutzer auf der Grundlage von Tagging erstellt**
Wenn die folgende Beispiel-Richtlinienanweisung an eine Rolle oder einen Benutzer angefügt wird, können Benutzer nur mit Notebooks arbeiten, die sie selbst erstellt haben. Diese Richtlinienanweisung verwendet das bei der Erstellung eines Notebooks angewendete Standard-Tag.
In diesem Beispiel versucht der Bedingungsoperator `StringEquals`, eine Variable, die die Benutzer-ID (`{aws:userId}`) des aktuellen Benutzers darstellt, dem Wert des Tags `creatorUserID` zuzuordnen. Wenn das Tag `creatorUserID` nicht zum Notebook hinzugefügt wurde oder den Wert der ID des aktuellen Benutzers nicht enthält, ist die Richtlinie nicht anzuwenden und die Aktionen werden von dieser Richtlinie nicht zugelassen. Wenn keine anderen Richtlinienanweisungen die Aktionen zulassen, kann der Benutzer nur mit Notebooks arbeiten, die dieses Tag mit diesem Wert enthalten.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:DescribeEditor",
"elasticmapreduce:StartEditor",
"elasticmapreduce:StopEditor",
"elasticmapreduce:DeleteEditor",
"elasticmapreduce:OpenEditorInConsole"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/creatorUserId": "${aws:userId}"
}
},
"Sid": "AllowELASTICMAPREDUCEDescribeeditor"
}
]
}
```
**Example – Notebook-Tagging anfordern, wenn ein Notebook erstellt wird**
In diesem Beispiel wird der Kontextschlüssel `RequestTag` verwendet. Die Aktion `CreateEditor` ist nur dann zulässig, wenn der Benutzer das `creatorUserID` Tag, das standardmäßig hinzugefügt wird, nicht ändert oder löscht. Die Variable \$1\$1aws:userId\$1 gibt die Benutzer-ID des aktuell aktiven Benutzers an. Dies ist der Standardwert des Tags.
Die Richtlinienanweisung kann verwendet werden, um sicherzustellen, dass Benutzer das Tag `createUserId` nicht entfernen und dessen Wert nicht ändern.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:CreateEditor"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:RequestTag/creatorUserId": "${aws:userid}"
}
},
"Sid": "AllowELASTICMAPREDUCECreateeditor"
}
]
}
```
Dieses Beispiel erfordert, dass der Benutzer den Cluster mit einem Tag mit der Schlüsselzeichenfolge `dept` und einem der folgenden Werte erstellt: `datascience`, `analytics`, `operations`.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:CreateEditor"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:RequestTag/dept": [
"datascience",
"analytics",
"operations"
]
}
},
"Sid": "AllowELASTICMAPREDUCECreateeditor"
}
]
}
```
**Example – Die Notebook-Erstellung auf getaggte Cluster beschränken und Notebook-Tags anfordern**
Dieses Beispiel erlaubt die Notebook-Erstellung nur, wenn das Notebook mit einem Tag erstellt wird, bei dem die Schlüsselzeichenfolge `owner` auf einen der angegebenen Werte festgelegt ist. Darüber hinaus kann das Notebook nur erstellt werden, wenn der Cluster ein Tag enthält, bei dem die Schlüsselzeichenfolge `department` auf einen der angegebenen Werte festgelegt ist.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:CreateEditor"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:RequestTag/owner": [
"owner1",
"owner2",
"owner3"
],
"elasticmapreduce:ResourceTag/department": [
"dep1",
"dep3"
]
}
},
"Sid": "AllowELASTICMAPREDUCECreateeditor"
}
]
}
```
**Example – Basierend auf Tags die Möglichkeit einschränken, ein Notebook zu starten**
Dieses Beispiel schränkt die Möglichkeit, ein Notebook zu starten, auf Notebooks ein, die ein Tag enthalten, bei dem die Schlüsselzeichenfolge `owner` auf einen der angegebenen Werte festgelegt ist. Da das Element `Resource` verwendet wird, um nur den `editor` anzugeben, gilt die Bedingung nicht für den Cluster und ein Tagging ist nicht erforderlich.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:StartEditor"
],
"Effect": "Allow",
"Resource": [
"arn:aws:elasticmapreduce:*:123456789012:editor/*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/owner": [
"owner1",
"owner2"
]
}
},
"Sid": "AllowELASTICMAPREDUCEStarteditor"
}
]
}
```
Dieses Beispiel ähnelt dem obigen. Die Einschränkung gilt hier jedoch nur für getaggte Cluster, nicht für Notebooks.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:StartEditor"
],
"Effect": "Allow",
"Resource": [
"arn:aws:elasticmapreduce:*:123456789012:cluster/*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/department": [
"dep1",
"dep3"
]
}
},
"Sid": "AllowELASTICMAPREDUCEStarteditor"
}
]
}
```
Dieses Beispiel verwendet andere Notebook- und Cluster-Tags. Es ermöglicht das Starten eines Notebooks nur, wenn Folgendes zutrifft:
+ Das Notebook enthält ein Tag, bei dem die Schlüsselzeichenfolge `owner` auf einen der angegebenen Wert festgelegt ist.
– und –
+ Der Cluster enthält ein Tag, bei dem die Schlüsselzeichenfolge `department` auf einen der angegebenen Wert festgelegt ist.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:StartEditor"
],
"Effect": "Allow",
"Resource": [
"arn:aws:elasticmapreduce:*:123456789012:editor/*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/owner": [
"user1",
"user2"
]
}
},
"Sid": "AllowELASTICMAPREDUCEStarteditorByOwner"
},
{
"Action": [
"elasticmapreduce:StartEditor"
],
"Effect": "Allow",
"Resource": [
"arn:aws:elasticmapreduce:*:123456789012:cluster/*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/department": [
"datascience",
"analytics"
]
}
},
"Sid": "AllowELASTICMAPREDUCEStarteditorByDepartment"
}
]
}
```
**Example – Basierend auf Tags die Möglichkeit einschränken, den Notebook-Editor zu öffnen**
In diesem Beispiel kann der Notebook-Editor nur geöffnet werden, wenn Folgendes zutrifft:
+ Das Notebook enthält ein Tag, bei dem die Schlüsselzeichenfolge `owner` auf einen der angegebenen Wert festgelegt ist.
– und –
+ Der Cluster enthält ein Tag, bei dem die Schlüsselzeichenfolge `department` auf einen der angegebenen Wert festgelegt ist.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:OpenEditorInConsole"
],
"Effect": "Allow",
"Resource": [
"arn:aws:elasticmapreduce:*:123456789012:editor/*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/owner": [
"user1",
"user2"
]
}
},
"Sid": "AllowELASTICMAPREDUCEOpeneditorconsoleByOwner"
},
{
"Action": [
"elasticmapreduce:OpenEditorInConsole"
],
"Effect": "Allow",
"Resource": [
"arn:aws:elasticmapreduce:*:123456789012:cluster/*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/department": [
"datascience",
"analytics"
]
}
},
"Sid": "AllowELASTICMAPREDUCEOpeneditorconsoleByDepartment"
}
]
}
```
# Die ModifyInstanceGroup Aktion in Amazon EMR ablehnen
Die [ModifyInstanceGroups](https://docs.aws.amazon.com/emr/latest/APIReference/API_ModifyInstanceGroups.html)Aktion in Amazon EMR erfordert nicht, dass Sie bei der Aktion eine Cluster-ID angeben. Stattdessen können Sie nur eine Instance-Gruppen-ID angeben. Aus diesem Grund hat eine scheinbar einfache Ablehnungsrichtlinie für diese Aktion, die auf der Cluster-ID oder einem Cluster-Tag basiert, möglicherweise nicht die beabsichtigte Wirkung. Betrachten Sie die folgende Beispielrichtlinie.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:ModifyInstanceGroups"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Sid": "AllowELASTICMAPREDUCEModifyinstancegroups"
},
{
"Action": [
"elasticmapreduce:ModifyInstanceGroups"
],
"Effect": "Deny",
"Resource": [
"arn:aws:elasticmapreduce:us-east-1:123456789012:cluster/j-12345ABCDEFG67"
],
"Sid": "DenyELASTICMAPREDUCEModifyinstancegroups"
}
]
}
```
------
Wenn ein Benutzer, dem diese Richtlinie zugewiesen ist, eine `ModifyInstanceGroup`-Aktion ausführt und nur die Instance-Gruppen-ID angibt, gilt die Richtlinie nicht. Da die Aktion für alle anderen Ressourcen zulässig ist, ist die Aktion erfolgreich.
Eine Lösung für dieses Problem besteht darin, der Identität eine Richtlinienerklärung beizufügen, die ein [NotResource](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_notresource.html)Element verwendet, um jede `ModifyInstanceGroup` Aktion abzulehnen, die ohne Cluster-ID ausgeführt wird. Die folgende Beispielrichtlinie fügt eine solche Deny-Anweisung hinzu, sodass jede `ModifyInstanceGroups`-Anfrage fehlschlägt, sofern keine Cluster-ID angegeben ist. Da eine Identität bei der Aktion eine Cluster-ID angeben muss, sind Ablehnungsbefehle, die auf der Cluster-ID basieren, daher wirksam.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:ModifyInstanceGroups"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Sid": "AllowELASTICMAPREDUCEModifyinstancegroups"
},
{
"Action": [
"elasticmapreduce:ModifyInstanceGroups"
],
"Effect": "Deny",
"Resource": [
"arn:aws:elasticmapreduce:us-east-1:123456789012:cluster/j-12345ABCDEFG67"
],
"Sid": "DenyELASTICMAPREDUCEModifyinstancegroupsSpecificCluster"
},
{
"Action": [
"elasticmapreduce:ModifyInstanceGroups"
],
"Effect": "Deny",
"NotResource": "arn:*:elasticmapreduce:*:*:cluster/*",
"Sid": "DenyELASTICMAPREDUCEModifyinstancegroupsNonCluster"
}
]
}
```
------
Ein ähnliches Problem tritt auf, wenn Sie die `ModifyInstanceGroups`-Aktion auf der Grundlage des mit einem Cluster-Tag verknüpften Werts ablehnen möchten. Die Lösung ist ähnlich. Zusätzlich zu einer Ablehnungs-Anweisung, die den Tag-Wert angibt, können Sie eine Richtlinienanweisung hinzufügen, die die `ModifyInstanceGroup`-Aktion ablehnt, wenn das von Ihnen angegebene Tag nicht vorhanden ist, unabhängig vom Wert.
Das folgende Beispiel zeigt eine Richtlinie, die, wenn sie an eine Identität angehängt ist, der Identität die `ModifyInstanceGroups`-Aktion aller Cluster verweigert, bei denen das Tag `department` auf `dev` gesetzt ist. Diese Anweisung ist nur aufgrund der Ablehnungs-Anweisung wirksam, die die `StringNotLike`-Bedingung verwendet, um die Aktion zu verweigern, sofern das `department`-Tag nicht vorhanden ist.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:ModifyInstanceGroups"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Sid": "AllowELASTICMAPREDUCEModifyinstancegroups"
},
{
"Action": [
"elasticmapreduce:ModifyInstanceGroups"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/department": "dev"
}
},
"Effect": "Deny",
"Resource": [
"*"
],
"Sid": "DenyELASTICMAPREDUCEModifyinstancegroupsDevDepartment"
},
{
"Action": [
"elasticmapreduce:ModifyInstanceGroups"
],
"Condition": {
"StringNotLike": {
"aws:ResourceTag/department": "?*"
}
},
"Effect": "Deny",
"Resource": [
"*"
],
"Sid": "DenyELASTICMAPREDUCEModifyinstancegroupsNoDepartmentTag"
}
]
}
```
------
# Fehlerbehebung für Amazon-EMR-Identität und -Zugriff
Diagnostizieren und beheben Sie mithilfe der folgenden Informationen gängige Probleme, die bei der Verwendung von Amazon EMR und IAM auftreten können.
**Topics**
+ [Ich bin nicht autorisiert, eine Aktion in Amazon EMR auszuführen](#security_iam_troubleshoot-no-permissions)
+ [Ich bin nicht berechtigt, iam durchzuführen: PassRole](#security_iam_troubleshoot-passrole)
+ [Ich möchte Personen außerhalb meines AWS Kontos den Zugriff auf meine Amazon EMR-Ressourcen ermöglichen](#security_iam_troubleshoot-cross-account-access)
## Ich bin nicht autorisiert, eine Aktion in Amazon EMR auszuführen
Wenn Ihnen AWS-Managementkonsole mitgeteilt wird, dass Sie nicht berechtigt sind, eine Aktion auszuführen, müssen Sie sich an Ihren Administrator wenden, um Unterstützung zu erhalten. Ihr Administrator ist die Person, die Ihnen Ihren Benutzernamen und Ihr Passwort zur Verfügung gestellt hat.
Der folgende Beispielfehler tritt auf, wenn der `mateojackson`-Benutzer versucht, die Konsole zum Anzeigen von Details zu einer fiktiven `my-example-widget`-Ressource zu verwenden, jedoch nicht über `EMR:GetWidget`-Berechtigungen verfügt.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: EMR:GetWidget on resource: my-example-widget
```
In diesem Fall bittet Mateo seinen Administrator um die Aktualisierung seiner Richtlinien, um unter Verwendung der Aktion `my-example-widget` auf die Ressource `EMR:GetWidget` zugreifen zu können.
## Ich bin nicht berechtigt, iam durchzuführen: PassRole
Wenn Sie die Fehlermeldung erhalten, dass Sie nicht zur Ausführung der Aktion `iam:PassRole` autorisiert sind, müssen Ihre Richtlinien aktualisiert werden, um eine Rolle an Amazon EMR übergeben zu können.
Einige AWS-Services ermöglichen es Ihnen, eine bestehende Rolle an diesen Dienst zu übergeben, anstatt eine neue Servicerolle oder eine dienstverknüpfte Rolle zu erstellen. Hierzu benötigen Sie Berechtigungen für die Übergabe der Rolle an den Dienst.
Der folgende Beispielfehler tritt auf, wenn ein IAM-Benutzer mit dem Namen `marymajor` versucht, die Konsole zu verwenden, um eine Aktion in Amazon EMR auszuführen. Die Aktion erfordert jedoch, dass der Service über Berechtigungen verfügt, die durch eine Servicerolle gewährt werden. Mary besitzt keine Berechtigungen für die Übergabe der Rolle an den Dienst.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
In diesem Fall müssen die Richtlinien von Mary aktualisiert werden, um die Aktion `iam:PassRole` ausführen zu können.
Wenn Sie Hilfe benötigen, wenden Sie sich an Ihren AWS Administrator. Ihr Administrator hat Ihnen Ihre Anmeldeinformationen zur Verfügung gestellt.
## Ich möchte Personen außerhalb meines AWS Kontos den Zugriff auf meine Amazon EMR-Ressourcen ermöglichen
Sie können eine Rolle erstellen, mit der Benutzer in anderen Konten oder Personen außerhalb Ihrer Organisation auf Ihre Ressourcen zugreifen können. Sie können festlegen, wem die Übernahme der Rolle anvertraut wird. Für Dienste, die ressourcenbasierte Richtlinien oder Zugriffskontrolllisten (ACLs) unterstützen, können Sie diese Richtlinien verwenden, um Personen Zugriff auf Ihre Ressourcen zu gewähren.
Weitere Informationen dazu finden Sie hier:
+ Informationen dazu, ob Amazon EMR diese Features unterstützt, finden Sie unter [Funktionsweise von Amazon EMR mit IAM](security_iam_service-with-iam.md).
+ *Informationen dazu, wie Sie Zugriff auf Ihre Ressourcen in AWS-Konten Ihrem Besitz gewähren können, finden Sie im IAM-Benutzerhandbuch unter [Gewähren des Zugriffs für einen IAM-Benutzer in einem anderen AWS-Konto , dem Sie](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) gehören.*
+ Informationen dazu, wie Sie Dritten Zugriff auf Ihre Ressourcen gewähren können AWS-Konten, finden Sie [AWS-Konten im *IAM-Benutzerhandbuch* unter Gewähren des Zugriffs für Dritte](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html).
+ Informationen dazu, wie Sie über einen Identitätsverbund Zugriff gewähren, finden Sie unter [Gewähren von Zugriff für extern authentifizierte Benutzer (Identitätsverbund)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) im *IAM-Benutzerhandbuch*.
+ Informationen zum Unterschied zwischen der Verwendung von Rollen und ressourcenbasierten Richtlinien für den kontoübergreifenden Zugriff finden Sie unter [Kontoübergreifender Ressourcenzugriff in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) im *IAM-Benutzerhandbuch*.
# Verwenden von Amazon S3 Access Grants mit Amazon EMR
## Übersicht über S3 Access Grants für Amazon EMR
Mit den Amazon-EMR-Versionen 6.15.0 und höher bieten Amazon S3 Access Grants eine skalierbare Zugriffskontrolllösung, mit der Sie den Zugriff auf Ihre Amazon-S3-Daten von Amazon EMR aus erweitern können. Wenn Sie für Ihre S3-Daten eine komplexe oder umfangreiche Berechtigungskonfiguration haben, können Sie mit S3 Access Grants die S3-Datenberechtigungen für Benutzer, Gruppen, Rollen und Anwendungen in Ihrem Cluster skalieren.
Verwenden Sie S3 Access Grants, um den Zugriff auf Amazon-S3-Daten über die Berechtigungen hinaus zu erweitern, die durch die Laufzeitrolle oder die IAM-Rollen gewährt werden, die den Identitäten mit Zugriff auf Ihren EMR-Cluster zugewiesen sind. Weitere Informationen finden Sie unter [Verwalten des Zugriffs mit S3 Access Grants](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-grants.html) im *Benutzerhandbuch zu Amazon S3*.
Schritte zur Verwendung von S3 Access Grants mit anderen Amazon-EMR-Bereitstellungen finden Sie in der folgenden Dokumentation:
+ [Verwenden von S3 Access Grants mit Amazon EMR in EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/access-grants.html)
+ [Verwenden von S3 Access Grants mit Amazon EMR Serverless](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/access-grants.html)
## So funktioniert Amazon EMR mit S3 Access Grants
Amazon-EMR-Versionen 6.15.0 und höher bieten eine native Integration mit S3 Access Grants. Sie können S3 Access Grants in Amazon EMR aktivieren und Spark-Aufträge ausführen. Wenn ein Spark-Auftrag eine Anfrage für S3-Daten stellt, stellt Amazon S3 temporäre Anmeldeinformationen bereit, die auf den jeweiligen Bucket, das Präfix oder das Objekt beschränkt sind.
Nachfolgend finden Sie einen allgemeinen Überblick darüber, wie Amazon EMR Zugriff auf Daten erhält, die durch S3 Access Grants geschützt sind.
![\[So funktioniert Amazon EMR mit S3 Access Grants\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/images/access-grants-overview.png)
1. Ein Benutzer reicht einen Amazon-EMR-Spark-Auftrag ein, der in Amazon S3 gespeicherte Daten verwendet.
1. Amazon EMR stellt eine Anfrage für S3 Access Grants, um im Namen dieses Benutzers Zugriff auf den Bucket, das Präfix oder das Objekt zu gewähren.
1. Amazon S3 gibt temporäre Anmeldeinformationen in Form eines AWS -Security-Token-Service (STS-) Tokens für den Benutzer zurück. Das Token ist für den Zugriff auf den S3-Bucket, das S3-Präfix oder das S3-Objekt vorgesehen.
1. Amazon EMR verwendet das STS-Token, um Daten aus S3 abzurufen.
1. Amazon EMR empfängt die Daten von S3 und gibt die Ergebnisse an den Benutzer zurück.
## Überlegungen zu S3 Access Grants mit Amazon EMR
Beachten Sie die folgenden Verhaltensweisen und Einschränkungen, wenn Sie S3 Access Grants mit Amazon EMR verwenden.
### Feature-Unterstützung
+ S3 Access Grants wird mit den Amazon-EMR-Versionen 6.15.0 und höher unterstützt.
+ Spark ist die einzige unterstützte Abfrage-Engine, wenn Sie S3 Access Grants mit Amazon EMR verwenden.
+ Delta Lake und Hudi sind die einzigen unterstützten Open-Table-Formate, wenn Sie S3 Access Grants mit Amazon EMR verwenden.
+ Die folgenden Amazon-EMR-Funktionen werden bei der Verwendung mit S3 Access Grants nicht unterstützt:
+ Apache-Iceberg-Tabellen
+ Native LDAP-Authentifizierung
+ Native Apache-Ranger-Authentifizierung
+ AWS CLI Anfragen an Amazon S3, die IAM-Rollen verwenden
+ S3-Zugriff über das Open-Source-Protokoll S3A
+ Die Option `fallbackToIAM` wird nicht für EMR-Cluster unterstützt, die die Verbreitung vertrauenswürdiger Identitäten mit IAM Identity Center verwenden.
+ [S3 Access Grants mit AWS Lake Formation](#emr-access-grants-lf) wird nur mit Amazon-EMR-Clustern unterstützt, die in Amazon EC2 ausgeführt werden.
### Überlegungen in Bezug auf das Verhalten
+ Die native Apache-Ranger-Integration in Amazon EMR bietet Funktionen, die S3 Access Grants als Teil des Plugins EMRFS S3 Apache Ranger entsprechen. Wenn Sie Apache Ranger für differenzierte Zugriffskontrolle (FGAC) verwenden, empfehlen wir, dieses Plugin anstelle von S3 Access Grants zu verwenden.
+ Amazon EMR stellt einen Cache für Anmeldeinformationen in EMRFS bereit, um sicherzustellen, dass ein Benutzer innerhalb eines Spark-Auftrags nicht wiederholt dieselben Anmeldeinformationen anfordern muss. Daher fordert Amazon EMR bei der Anforderung von Anmeldeinformationen immer die Standardberechtigung an. Weitere Informationen finden Sie unter [Zugriff auf S3-Daten anfordern](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-grants-credentials.html) im *Benutzerhandbuch zu Amazon S3*.
+ Für den Fall, dass ein Benutzer eine Aktion ausführt, die S3 Access Grants nicht unterstützt, ist Amazon EMR so eingestellt, dass es die IAM-Rolle verwendet, die für die Auftragsausführung angegeben wurde. Weitere Informationen finden Sie unter [Fallback auf IAM-Rollen](#emr-access-grants-fallback).
## Starten eines Amazon-EMR-Clusters mit S3 Access Grants
In diesem Abschnitt wird beschrieben, wie Sie einen EMR-Cluster starten, der in Amazon EC2 läuft und S3 Access Grants verwendet, um den Zugriff auf Daten in Amazon S3 zu verwalten. Schritte zur Verwendung von S3 Access Grants mit anderen Amazon-EMR-Bereitstellungen finden Sie in der folgenden Dokumentation:
+ [Verwenden von S3 Access Grants mit Amazon EMR in EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/access-grants.html)
+ [Verwenden von S3 Access Grants mit EMR Serverless](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/access-grants.html)
Gehen Sie wie folgt vor, um einen EMR-Cluster zu starten, der in Amazon EC2 läuft und S3 Access Grants verwendet, um den Zugriff auf Daten in Amazon S3 zu verwalten.
1. Richten Sie eine Auftragsausführungsrolle für Ihren EMR-Cluster ein. Geben Sie die erforderlichen IAM-Berechtigungen an, die Sie für die Ausführung von Spark-Aufträgen benötigen, `s3:GetDataAccess` und `s3:GetAccessGrantsInstanceForPrefix`:
```
{
"Effect": "Allow",
"Action": [
"s3:GetDataAccess",
"s3:GetAccessGrantsInstanceForPrefix"
],
"Resource": [ //LIST ALL INSTANCE ARNS THAT THE ROLE IS ALLOWED TO QUERY
"arn:aws_partition:s3:Region:account-id1:access-grants/default",
"arn:aws_partition:s3:Region:account-id2:access-grants/default"
]
}
```
**Anmerkung**
Mit Amazon EMR erweitern S3 Access Grants die Berechtigungen, die in IAM-Rollen festgelegt sind. Wenn die IAM-Rollen, die Sie für die Auftragsausführung angeben, Berechtigungen für den direkten Zugriff auf S3 enthalten, können Benutzer möglicherweise auf mehr Daten zugreifen als nur auf die Daten, die Sie in S3 Access Grants definieren.
1. Verwenden Sie als Nächstes die, AWS CLI um einen Cluster mit Amazon EMR 6.15 oder höher und die `emrfs-site` Klassifizierung zu erstellen, um S3 Access Grants zu aktivieren, ähnlich dem folgenden Beispiel:
```
aws emr create-cluster
--release-label emr-6.15.0 \
--instance-count 3 \
--instance-type m5.xlarge \
--configurations '[{"Classification":"emrfs-site", "Properties":{"fs.s3.s3AccessGrants.enabled":"true", "fs.s3.s3AccessGrants.fallbackToIAM":"false"}}]'
```
## S3 Access Grants mit AWS Lake Formation
Wenn Sie Amazon EMR mit der [AWS Lake Formation -Integration](emr-lake-formation.md) verwenden, können Sie Amazon S3 Access Grants für direkten oder tabellarischen Zugriff auf Daten in Amazon S3 verwenden.
**Anmerkung**
S3 Access Grants mit AWS Lake Formation wird nur mit Amazon EMR-Clustern unterstützt, die auf Amazon EC2 ausgeführt werden.
**Direkter Zugriff**
Der direkte Zugriff umfasst alle Aufrufe zum Zugriff auf S3-Daten, die nicht die API für den AWS Glue-Service aufrufen, den Lake Formation als Metastore mit Amazon EMR verwendet, zum Beispiel, um Folgendes aufzurufen: `spark.read`
```
spark.read.csv("s3://...")
```
Wenn Sie S3 Access Grants AWS Lake Formation auf Amazon EMR verwenden, durchlaufen alle Direktzugriffsmuster S3 Access Grants, um temporäre S3-Anmeldeinformationen zu erhalten.
**Tabellarischer Zugriff**
Ein tabellarischer Zugriff erfolgt, wenn Lake Formation die Metastore-API aufruft, um auf Ihren S3-Standort zuzugreifen, z. B. um Tabellendaten abzufragen:
```
spark.sql("select * from test_tbl")
```
Wenn Sie S3 Access Grants mit AWS Lake Formation auf Amazon EMR verwenden, durchlaufen alle tabellarischen Zugriffsmuster Lake Formation.
## Fallback auf IAM-Rollen
Wenn ein Benutzer versucht, eine Aktion auszuführen, die S3 Access Grants nicht unterstützt, wird Amazon EMR standardmäßig die IAM-Rolle verwenden, die für die Auftragsausführung angegeben wurde, wenn die `fallbackToIAM`-Konfiguration `true` ist. Auf diese Weise können Benutzer in Szenarien, die S3 Access Grants nicht abdeckt, auf ihre Auftragsausführungsrolle zurückgreifen, um Anmeldeinformationen für den S3-Zugriff einzugeben.
Wenn `fallbackToIAM` aktiviert ist, können Benutzer auf die Daten zugreifen, die Access Grant zulässt. Wenn es kein S3-Access-Grants-Token für die Zieldaten gibt, überprüft Amazon EMR, ob die entsprechende Berechtigung für die Auftragsausführungsrolle vorliegt.
**Anmerkung**
Wir empfehlen Ihnen, Ihre Zugriffsberechtigungen bei aktivierter `fallbackToIAM`-Konfiguration zu testen, auch wenn Sie planen, die Option für Produktionsworkloads zu deaktivieren. Bei Spark-Aufträgen gibt es andere Möglichkeiten, wie Benutzer mit ihren IAM-Anmeldeinformationen auf alle Berechtigungssätze zugreifen können. Wenn sie auf EMR-Clustern aktiviert sind, gewähren S3-Erteilungen Spark-Aufträgen Zugriff auf S3-Standorte. Sie sollten sicherstellen, dass Sie diese S3-Standorte vor Zugriffen außerhalb von EMRFS schützen. Sie sollten die S3-Standorte beispielsweise vor dem Zugriff durch S3-Clients schützen, die in Notebooks verwendet werden, oder durch Anwendungen, die nicht von S3 Access Grants unterstützt werden, wie Hive oder Presto.
# Authentifizieren von Amazon-EMR-Cluster-Knoten
SSH-Clients können mit einem Amazon-EC2-Schlüsselpaar Cluster-Instances authentifizieren. Alternativ können Sie bei Amazon EMR Version 5.10.0 oder höher Kerberos so konfigurieren, dass Benutzer und SSH-Verbindungen gegenüber dem Primärknoten authentifiziert werden. Und mit den Amazon-EMR-Versionen 5.12.0 und höher können Sie sich mit LDAP authentifizieren.
**Topics**
+ [Verwenden Sie ein EC2-Schlüsselpaar für SSH-Anmeldeinformationen für Amazon EMR](emr-plan-access-ssh.md)
+ [Verwenden Sie Kerberos für die Authentifizierung mit Amazon EMR](emr-kerberos.md)
+ [Active-Directory- oder LDAP-Server für die Authentifizierung mit Amazon EMR verwenden](ldap.md)
# Verwenden Sie ein EC2-Schlüsselpaar für SSH-Anmeldeinformationen für Amazon EMR
Amazon-EMR-Clusterknoten werden auf Amazon-EC2-Instances ausgeführt. Sie können mit Cluster-Knoten auf die gleiche Weise eine Verbindung herstellen wie mit Amazon-EC2-Instances. Mit Amazon EC2 können Sie ein Schlüsselpaar erstellen, oder Sie können ein Schlüsselpaar importieren. Wenn Sie einen Cluster erstellen, können Sie das Amazon-EC2-Schlüsselpaar angeben, das für SSH-Verbindungen mit allen Cluster-Instances verwendet wird. Außerdem können Sie auch einen Cluster ohne ein Schlüsselpaar erstellen. Dies geschieht normalerweise mit vorübergehenden Clusters, die starten, gewisse Schritte ausführen und dann automatisch beendet werden.
Der SSH-Client, mit dem Sie sich mit dem Cluster verbinden, benötigt die Datei mit dem privaten Schlüssel, der mit diesem Schlüsselpaar verknüpft ist. Dies ist eine .pem-Datei für SSH-Clients unter Linux, Unix und macOS. Sie müssen die Berechtigungen so festlegen, dass nur der Schlüsselbesitzer berechtigt ist, auf die Datei zuzugreifen. Dies ist eine.ppk-Datei für SSH-Clients mit Windows, und die.ppk-Datei wird in der Regel von der .pem-Datei erstellt.
+ Weitere Informationen zum Erstellen eines Amazon EC2 EC2-Schlüsselpaars finden Sie unter [Amazon EC2 EC2-Schlüsselpaare](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) im *Amazon EC2 EC2-Benutzerhandbuch*.
+ Anweisungen zur Verwendung von Pu TTYgen zum Erstellen einer .ppk-Datei aus einer .pem-Datei finden Sie unter [Konvertieren Ihres privaten Schlüssels mit Pu TTYgen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html#putty-private-key) im *Amazon* EC2 EC2-Benutzerhandbuch.
+ Weitere Informationen zum Festlegen von Zugriffsberechtigungen für PEM-Dateien und zum Herstellen einer Verbindung mit dem primären Knoten eines EMR-Clusters mithilfe verschiedener Methoden — einschließlich `ssh` Linux oder macOS, PuTTY unter Windows oder von einem beliebigen unterstützten Betriebssystem AWS CLI aus — finden Sie unter. [Stellen Sie mithilfe von SSH eine Connect zum primären Knoten des Amazon EMR-Clusters her](emr-connect-master-node-ssh.md)
# Verwenden Sie Kerberos für die Authentifizierung mit Amazon EMR
Amazon-EMR-Versionen 5.10.0 und höher unterstützen Kerberos. Kerberos ist ein Netzwerkauthentifizierungsprotokoll, das eine Verschlüsselung mit geheimen Schlüsseln verwendet, um eine starke Authentifizierung bereitzustellen, sodass Passwörter oder andere Anmeldeinformationen nicht in einem unverschlüsselten Format über das Netzwerk gesendet werden.
In Kerberos werden Services und Benutzer, die sich authentifizieren müssen, als *Prinzipale* bezeichnet. Prinzipale befinden sich in einem Kerberos-*Bereich*. Innerhalb des Bereichs gewährt ein Kerberos-Server, der als *Key Distribution Center (KDC)* bezeichnet wird, Prinzipalen die Möglichkeit, sich zu authentifizieren. Dazu stellt das KDC *Tickets* für die Authentifizierung aus. Das KDC unterhält eine Datenbank der Prinzipale in seinem Bereich mit ihren Passwörtern und anderen administrativen Informationen zu jedem Prinzipal. Ein KDC kann auch Anmeldeinformationen für die Authentifizierung von Prinzipalen aus anderen Bereichen akzeptieren. Dies wird als *bereichsübergreifendes Vertrauen* bezeichnet. Darüber hinaus kann ein EMR-Cluster ein externes KDC verwenden, um Prinzipale zu authentifizieren.
Ein gängiges Szenario für die Einrichtung einer bereichsübergreifenden Vertrauensstellung oder für die Verwendung eines externen KDC ist die Authentifizierung von Benutzern von einer Active-Directory-Domain aus. Auf diese Weise können Benutzer mit ihrem Domainkonto auf einen EMR-Cluster zugreifen, wenn sie SSH verwenden, um eine Verbindung zu einem Cluster herzustellen oder mit Big-Data-Anwendungen zu arbeiten.
Bei Verwendung der Kerberos-Authentifizierung konfiguriert Amazon EMR Kerberos für die Anwendungen, Komponenten und Subsysteme, die es auf dem Cluster installiert, damit sie gegenseitig authentifiziert werden.
**Wichtig**
Amazon EMR unterstützt nicht AWS Directory Service for Microsoft Active Directory in einem realmübergreifenden Trust oder als externes KDC.
Bevor Sie Kerberos mit Amazon EMR konfigurieren, empfehlen wir, dass Sie sich über Kerberos-Konzepte, die Services für die Ausführung auf einem KDC und die Tools für die Verwaltung von Kerberos-Services informieren. Weitere Informationen finden Sie in der [MIT-Kerberos-Dokumentation](http://web.mit.edu/kerberos/krb5-latest/doc/), die vom [Kerberos Consortium](http://kerberos.org/) veröffentlicht wird.
**Topics**
+ [Unterstützte Anwendungen mit Amazon EMR](emr-kerberos-principals.md)
+ [Kerberos-Architekturoptionen mit Amazon EMR](emr-kerberos-options.md)
+ [Konfiguration von Kerberos in Amazon EMR](emr-kerberos-configure.md)
+ [Verwenden von SSH zum Herstellen einer Verbindung zu kerberisierten Clustern mit Amazon EMR](emr-kerberos-connect-ssh.md)
+ [Tutorial: Konfiguration eines clusterspezifischen KDC mit Amazon EMR](emr-kerberos-cluster-kdc.md)
+ [Tutorial: Konfigurieren einer bereichsübergreifenden Vertrauensstellung mit einer Active-Directory-Domain](emr-kerberos-cross-realm.md)
# Unterstützte Anwendungen mit Amazon EMR
In einem EMR-Cluster sind Kerberos-Prinzipale die Big Data-Anwendungsservices und Sub-Systemen, die auf allen Cluster-Knoten ausgeführt werden. Amazon EMR kann die Anwendungen und die unten aufgeführten Komponenten für die Verwendung von Kerberos konfigurieren. Jeder Anwendung ist ein Kerberos-Benutzer-Prinzipal zugeordnet.
Amazon EMR unterstützt kein bereichsübergreifendes Vertrauen für AWS Directory Service for Microsoft Active Directory.
Amazon EMR konfiguriert nur die Open-Source-Authentifizierungsfeatures für Kerberos für die unten aufgelisteten Anwendungen und Komponenten. Alle anderen installierten Anwendungen sind nicht durch Kerberos geschützt. Dies kann zu einer Unfähigkeit der Kommunikation mit durch Kerberos geschützten Komponenten führen und Anwendungsfehler verursachen. Für Anwendungen und Komponenten, die nicht durch Kerberos geschützt sind, ist keine Authentifizierung aktiviert. Die unterstützten Anwendungen und Komponenten können je nach Amazon EMR Versionen variieren.
Die Livy-Benutzeroberfläche ist die einzige Weboberfläche, die auf dem Kerberized Cluster gehostet wird.
+ **Hadoop MapReduce**
+ **Hbase**
+ **HCatalog**
+ **HDFS**
+ **Hive**
+ Aktivieren Sie keine Hive mit LDAP-Authentifizierung. Dies kann Probleme bei der Kommunikation mit durch Kerberos geschütztem YARN verursachen.
+ **Hue**
+ Die Hue-Benutzerauthentifizierung wird nicht automatisch eingerichtet und kann unter Verwendung der Konfigurations-API konfiguriert werden.
+ Der Hue-Server ist durch Kerberos geschützt. Das Hue Front-End (UI) ist nicht für die Authentifizierung konfiguriert. Die LDAP-Authentifizierung kann für die Hue-UI konfiguriert werden.
+ **Livy**
+ Livy-Identitätswechsel mit kerberisierten Clustern wird in Amazon-EMR-Versionen 5.22.0 und höher unterstützt.
+ **Oozie**
+ **Phoenix**
+ **Presto**
+ Presto unterstützt die Kerberos-Authentifizierung in Amazon-EMR-Versionen 6.9.0 und höher.
+ [Um die Kerberos-Authentifizierung für Presto zu verwenden, müssen Sie die Verschlüsselung bei der Übertragung aktivieren.](emr-data-encryption-options.md#emr-encryption-intransit)
+ **Spark**
+ **Tez**
+ **Trino**
+ Trino unterstützt die Kerberos-Authentifizierung in Amazon-EMR-Versionen 6.11.0 und höher.
+ [Um die Kerberos-Authentifizierung für Trino zu verwenden, müssen Sie die Verschlüsselung bei der Übertragung aktivieren.](emr-data-encryption-options.md#emr-encryption-intransit)
+ **YARN**
+ **Zeppelin**
+ Zeppelin ist nur mit dem Spark-Interpreter für die Verwendung von Kerberos konfiguriert. Es ist nicht für andere Interpreter konfiguriert.
+ Der Identitätswechsel von Benutzern wird für Kerberized-Zeppelin-Interpreter außer Spark nicht unterstützt.
+ **Zookeeper**
+ Der Zookeeper-Client wird nicht unterstützt.
# Kerberos-Architekturoptionen mit Amazon EMR
Wenn Sie Kerberos mit Amazon EMR verwenden, können Sie aus den in diesem Abschnitt aufgeführten Architekturen wählen. Unabhängig von der gewählten Architektur konfigurieren Sie Kerberos anhand der gleichen Schritte. Sie erstellen eine Sicherheitskonfiguration, legen die Sicherheitskonfiguration und kompatible Cluster-spezifische Kerberos-Optionen fest, wenn Sie den Cluster erstellen. Zudem erstellen Sie HDFS-Verzeichnisse für Linux-Benutzer auf dem Cluster, der den Benutzerprinzipalen auf dem KDC entspricht. Weitere Informationen zu Konfigurationsoptionen und Beispielkonfigurationen für jede Architektur finden Sie unter [Konfiguration von Kerberos in Amazon EMR](emr-kerberos-configure.md).
## Cluster-spezifisches KDC (KDC auf dem Primärknoten)
Diese Konfiguration ist nur mit Amazon-EMR-Versionen 5.10.0 und höher verfügbar.
![\[Amazon EMRCluster architecture with master node, core nodes, and task node within a Kerberos realm.\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/images/kerb-cluster-dedicated-kdc.png)
**Vorteile**
+ Amazon EMR ist im vollständigen Besitz des KDC.
+ Das KDC auf dem EMR-Cluster ist unabhängig von zentralisierten KDC-Implementierungen wie Microsoft Active Directory oder AWS Managed Microsoft AD.
+ Die Auswirkungen auf die Performance sind minimal, da das KDC die Authentifizierung nur für lokale Knoten innerhalb des Clusters verwaltet.
+ Optional können andere Kerberos-Cluster auf das KDC als externes KDC verweisen. Weitere Informationen finden Sie unter [Externes KDC – Primärknoten auf einem anderen Cluster](#emr-kerberos-extkdc-cluster-summary).
**Überlegungen und Einschränkungen**
+ Kerberos-Cluster können einander nicht authentifizieren, sodass für die Anwendungen keine Interoperabilität besteht. Wenn Cluster-Anwendungen interagieren müssen, müssen Sie eine bereichsübergreifende Vertrauensstellung zwischen Clustern oder einen Cluster als externes KDC für andere Cluster einrichten. Wenn eine realmübergreifende Vertrauensstellung eingerichtet wird, KDCs müssen sie über unterschiedliche Kerberos-Bereiche verfügen.
+ Erstellen Sie Linux-Benutzer auf der EC2-Instance des Primärknotens, der den KDC-Benutzerprinzipalen entspricht, zusammen mit den HDFS-Verzeichnissen für jeden Benutzer.
+ Benutzerprinzipale müssen eine EC2-Datei mit privatem Schlüssel und `kinit`-Anmeldeinformationen verwenden, um mittels SSH eine Verbindung zum Cluster herzustellen.
## Bereichsübergreifende Vertrauensstellung
In dieser Konfiguration werden Prinzipale (in der Regel Benutzer) aus einem anderen Kerberos-Bereich an den Anwendungskomponenten auf einem durch Kerberos geschützten EMR-Cluster authentifiziert, der über ein eigenes KDC verfügt. Das KDC auf dem primären Knoten baut mithilfe eines *realmübergreifenden* Prinzipals, das in beiden vorhanden ist, eine Vertrauensstellung mit einem anderen KDC auf. KDCs Der Name des Prinzipals und das Passwort stimmen in jedem KDC genau überein. Bereichsübergreifende Vertrauensstellungen kommen am häufigsten in Active Directory-Implementierungen vor, wie in der folgenden Abbildung dargestellt. Bereichsübergreifende Vertrauensstellungen mit einem externen MIT KDC oder einem KDC auf einem anderen Amazon–EMR Cluster werden ebenfalls unterstützt.
![\[Amazon EMR clusters in different Kerberos realms with cross-realm trust to Active Directory.\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/images/kerb-cross-realm-trust.png)
**Vorteile**
+ Der EMR-Cluster, auf dem das KDC installiert ist, ist im vollständigen Besitz des KDC.
+ Mit Active Directory erstellt Amazon EMR automatisch Linux-Benutzer, die Benutzerprinzipalen aus dem KDC entsprechen. Sie müssen dennoch für jeden Benutzer HDFS-Verzeichnisse erstellen. Darüber hinaus können Benutzerprinzipale in der Active-Directory-Domain mit `kinit`-Anmeldeinformationen durch Kerberos geschützte Cluster ohne die EC2-Datei mit privatem Schlüssel aufrufen. Dies beseitigt die Notwendigkeit, die Datei mit dem privaten Schlüssel für die Cluster-Benutzer freizugeben.
+ Da jedes Cluster-KDC die Authentifizierung für die Knoten im Cluster verwaltet, werden die Auswirkungen der Netzwerklatenz und des Verwaltungsaufwands für eine große Anzahl an Knoten in Clustern minimiert.
**Überlegungen und Einschränkungen**
+ Wenn Sie eine Vertrauensstellung mit einem Active-Directory-Bereich einrichten, müssen Sie beim Erstellen des Clusters Active Directory-Benutzername und -Passwort mit Berechtigungen zum Hinzufügen von Prinzipalen zur Domain angeben.
+ Bereichsübergreifende Vertrauensstellungen können nicht zwischen Kerberos-Bereichen mit demselben Namen eingerichtet werden.
+ Bereichsübergreifende Vertrauensstellungen müssen explizit eingerichtet werden. Beispiel: Wenn Cluster A und Cluster B eine bereichsübergreifende Vertrauensstellung mit einem KDC einrichten, vertrauen diese einander nicht inhärent und ihre Anwendungen können einander nicht authentifizieren, um miteinander zu interagieren.
+ KDCs muss unabhängig verwaltet und koordiniert werden, sodass die Anmeldeinformationen der Benutzerprinzipale exakt übereinstimmen.
## Externes KDC
Konfigurationen mit einem externen KDC werden mit Amazon EMR 5.20.0 und höher unterstützt.
+ [Externes KDC – MIT KDC](#emr-kerberos-extkdc-mit-summary)
+ [Externes KDC – Primärknoten auf einem anderen Cluster](#emr-kerberos-extkdc-cluster-summary)
+ [Externes KDC – Cluster-KDC mit anderer bereichsübergreifender Active-Directory-Vertrauensstellung](#emr-kerberos-extkdc-ad-trust-summary)
### Externes KDC – MIT KDC
Diese Konfiguration ermöglicht mindestens einem EMR-Cluster die Verwendung von Prinzipalen, die in einem MIT KDC-Server definiert und verwaltet werden.
![\[Amazon EMRCluster architecture with Kerberos realm, showing master, core, and task nodes.\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/images/kerb-external-kdc.png)
**Vorteile**
+ Die Verwaltung von Prinzipalen ist in einem einzigen KDC zusammengefasst.
+ Mehrere Cluster können dasselbe KDC im selben Kerberos-Bereich verwenden. Weitere Informationen finden Sie unter [Anforderungen für die Verwendung mehrerer Cluster mit demselben KDC](#emr-kerberos-multi-kdc).
+ Der Primärknoten auf einem durch Kerberos geschützten Cluster hat nicht die Performance-Einbußen zu verzeichnen wie der Unterhalt des KDC.
**Überlegungen und Einschränkungen**
+ Erstellen Sie Linux-Benutzer auf der EC2-Instance des Primärknotens vom allen durch Kerberos geschützten Clustern, die den KDC-Benutzerprinzipalen entsprechen, zusammen mit den HDFS-Verzeichnissen für jeden Benutzer.
+ Benutzerprinzipale müssen eine EC2-Datei mit privatem Schlüssel und `kinit`-Anmeldeinformationen verwenden, um mittels SSH eine Verbindung zu den durch Kerberos geschützten Clustern herzustellen.
+ Jeder Knoten in durch Kerberos geschützten EMR-Clustern muss über eine Netzwerkroute zum KDC verfügen.
+ Jeder -Knoten in durch Kerberos geschützten Clustern platziert auf dem externen KDC eine Authentifizierungshürde, sodass die Konfiguration des KDC sich auf die Cluster-Performance auswirkt. Berücksichtigen Sie bei der Konfiguration der Hardware des KDC-Servers die maximale Anzahl der Amazon-EMR-Knoten, die gleichzeitig unterstützt werden können.
+ Die Cluster-Performance hängt von der Netzwerklatenz zwischen Knoten in durch Kerberos geschützten Clustern und dem KDC ab.
+ Die Fehlerbehebung kann sich aufgrund von Abhängigkeiten untereinander schwieriger gestalten.
### Externes KDC – Primärknoten auf einem anderen Cluster
Diese Konfiguration ist nahezu identisch mit der oben erwähnten externen MIT KDC-Implementierung, mit der Ausnahme, dass sich das KDC auf dem Primärknoten eines EMR-Clusters befindet. Weitere Informationen erhalten Sie unter [Cluster-spezifisches KDC (KDC auf dem Primärknoten)](#emr-kerberos-localkdc-summary) und [Tutorial: Konfigurieren einer bereichsübergreifenden Vertrauensstellung mit einer Active-Directory-Domain](emr-kerberos-cross-realm.md).
![\[Diagram of Amazon EMR clusters with Kerberos realm, showing master and core nodes.\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/images/kerb-external-cluster-kdc.png)
**Vorteile**
+ Die Verwaltung von Prinzipalen ist in einem einzigen KDC zusammengefasst.
+ Mehrere Cluster können dasselbe KDC im selben Kerberos-Bereich verwenden. Weitere Informationen finden Sie unter [Anforderungen für die Verwendung mehrerer Cluster mit demselben KDC](#emr-kerberos-multi-kdc).
**Überlegungen und Einschränkungen**
+ Erstellen Sie Linux-Benutzer auf der EC2-Instance des Primärknotens vom allen durch Kerberos geschützten Clustern, die den KDC-Benutzerprinzipalen entsprechen, zusammen mit den HDFS-Verzeichnissen für jeden Benutzer.
+ Benutzerprinzipale müssen eine EC2-Datei mit privatem Schlüssel und `kinit`-Anmeldeinformationen verwenden, um mittels SSH eine Verbindung zu den durch Kerberos geschützten Clustern herzustellen.
+ Jeder Knoten in jedem EMR-Cluster muss über eine Netzwerkroute zum KDC verfügen.
+ Jeder Amazon-EMR-Knoten in durch Kerberos geschützten Clustern platziert auf dem externen KDC eine Authentifizierungshürde, sodass die Konfiguration des KDC sich auf die Cluster-Performance auswirkt. Berücksichtigen Sie bei der Konfiguration der Hardware des KDC-Servers die maximale Anzahl der Amazon-EMR-Knoten, die gleichzeitig unterstützt werden können.
+ Die Cluster-Performance hängt von der Netzwerklatenz zwischen Knoten in den Clustern und dem KDC ab.
+ Die Fehlerbehebung kann sich aufgrund von Abhängigkeiten untereinander schwieriger gestalten.
### Externes KDC – Cluster-KDC mit anderer bereichsübergreifender Active-Directory-Vertrauensstellung
Bei dieser Konfiguration erstellen Sie zunächst einen Cluster mit einem Cluster-spezifischen KDC, das eine unidirektionale bereichsübergreifende Vertrauensstellung mit Active Directory aufweist. Ein detailliertes Tutorial finden Sie unter [Tutorial: Konfigurieren einer bereichsübergreifenden Vertrauensstellung mit einer Active-Directory-Domain](emr-kerberos-cross-realm.md). Anschließend starten Sie zusätzliche Cluster, die auf das Cluster-KDC verweisen, das die Vertrauensstellung als externes KDC besitzt. Ein Beispiel finden Sie unter [Externes Cluster-KDC mit bereichsübergreifender Active-Directory-Vertrauensstellung](emr-kerberos-config-examples.md#emr-kerberos-example-extkdc-ad-trust). Auf diese Weise können Sie jedem Amazon-EMR-Cluster, der das externe KDC verwendet, die Authentifizierung von Prinzipalen erlauben, die in einer Domain von Microsoft Active Directory definiert und verwaltet werden.
![\[Amazon EMR clusters with Kerberos authentication and Active Directory integration diagram.\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/images/kerb-external-ad-trust-kdc.png)
**Vorteile**
+ Die Verwaltung von Prinzipalen ist in der Active-Directory-Domain zusammengefasst.
+ Amazon EMR tritt dem Active-Directory-Bereich bei. Dadurch müssen keine Linux-Benutzer mehr erstellt werden, die Active-Directory-Benutzern entsprechen. Sie müssen dennoch für jeden Benutzer HDFS-Verzeichnisse erstellen.
+ Mehrere Cluster können dasselbe KDC im selben Kerberos-Bereich verwenden. Weitere Informationen finden Sie unter [Anforderungen für die Verwendung mehrerer Cluster mit demselben KDC](#emr-kerberos-multi-kdc).
+ Benutzerprinzipale können in der Active-Directory-Domain mit `kinit`-Anmeldeinformationen durch Kerberos geschützte Cluster ohne die EC2-Datei mit privatem Schlüssel aufrufen. Dies beseitigt die Notwendigkeit, die Datei mit dem privaten Schlüssel für die Cluster-Benutzer freizugeben.
+ Da nur ein einziger Amazon-EMR-Primärknoten für die KDC-Verwaltung verantwortlich ist, muss nur dieser Cluster mit Active-Directory-Anmeldeinformationen erstellt werden, um die bereichsübergreifende Vertrauensstellung zwischen dem KDC und Active Directory herzustellen.
**Überlegungen und Einschränkungen**
+ Jeder Knoten in jedem EMR-Cluster muss über eine Netzwerkroute zum KDC und den Active-Directory-Domain-Controller verfügen.
+ Jeder Amazon-EMR-Knoten platziert auf dem externen KDC eine Authentifizierungshürde, sodass die Konfiguration des KDC sich auf die Cluster-Performance auswirkt. Berücksichtigen Sie bei der Konfiguration der Hardware des KDC-Servers die maximale Anzahl der Amazon-EMR-Knoten, die gleichzeitig unterstützt werden können.
+ Die Cluster-Performance hängt von der Netzwerklatenz zwischen Knoten in den Clustern und dem KDC-Server ab.
+ Die Fehlerbehebung kann sich aufgrund von Abhängigkeiten untereinander schwieriger gestalten.
## Anforderungen für die Verwendung mehrerer Cluster mit demselben KDC
Mehrere Cluster können dasselbe KDC im selben Kerberos-Bereich verwenden. Wenn die Cluster jedoch gleichzeitig ausgeführt werden, schlagen die Cluster möglicherweise fehl, wenn sie ServicePrincipal Kerberos-Namen verwenden, die zu Konflikten führen.
Wenn Sie mehrere gleichzeitige Cluster mit demselben externen KDC haben, stellen Sie sicher, dass die Cluster unterschiedliche Kerberos-Bereiche verwenden. Wenn die Cluster denselben Kerberos-Bereich verwenden müssen, stellen Sie sicher, dass sich die Cluster in unterschiedlichen Subnetzen befinden und dass sich ihre CIDR-Bereiche nicht überschneiden.
# Konfiguration von Kerberos in Amazon EMR
Dieser Abschnitt enthält Konfigurationsdetails und Beispiele für das Einrichten von Kerberos mit gängigen Architekturen. Unabhängig von der gewählten Architektur sind die Konfigurationsgrundlagen identisch und in drei Schritte unterteilt. Wenn Sie ein externes KDC verwenden oder eine bereichsübergreifende Vertrauensstellung einrichten, müssen Sie sicherstellen, dass alle Knoten in einem Cluster über eine Netzwerkroute zu einem externen KDC verfügen, einschließlich der Konfiguration der entsprechenden Sicherheitsgruppen, die den ein- und ausgehenden Kerberos-Datenverkehr erlauben.
## Schritt 1: Eine Sicherheitskonfiguration mit Kerberos-Eigenschaften erstellen
Die Sicherheitskonfiguration gibt Details über das Kerberos-KDC an und ermöglicht, dass die Kerberos-Konfiguration beim Erstellen eines Clusters wiederverwendet wird. Sie können eine Sicherheitskonfiguration mithilfe der Amazon EMR-Konsole AWS CLI, der oder der EMR-API erstellen. Die Sicherheitskonfiguration kann auch andere Sicherheitsoptionen enthalten, wie beispielsweise die Verschlüsselung. Weitere Informationen zum Erstellen von Sicherheitskonfigurationen und Festlegen einer Sicherheitskonfiguration beim Erstellen eines Clusters finden Sie unter [Verwenden Sie Sicherheitskonfigurationen, um die Amazon EMR-Cluster-Sicherheit einzurichten](emr-security-configurations.md). Informationen zu Kerberos-Eigenschaften in einer Sicherheitskonfiguration finden Sie unter [Kerberos-Einstellungen für Sicherheitskonfigurationen](emr-kerberos-configure-settings.md#emr-kerberos-security-configuration).
## Schritt 2: Einen Cluster erstellen und Cluster-spezifische Kerberos-Attribute festlegen
Beim Erstellen eines Clusters legen Sie eine Kerberos-Sicherheitskonfiguration sowie Cluster-spezifische Kerberos-Optionen fest. Wenn Sie die Amazon-EMR-Konsole verwenden, sind nur die mit der angegebenen Sicherheitskonfiguration kompatiblen Kerberos-Optionen verfügbar. Wenn Sie die AWS CLI oder Amazon EMR-API verwenden, stellen Sie sicher, dass Sie Kerberos-Optionen angeben, die mit der angegebenen Sicherheitskonfiguration kompatibel sind. Beispiel: Wenn Sie beim Erstellen eines Clusters mithilfe der CLI ein Prinzipal-Passwort für eine bereichsübergreifende Vertrauensstellung verwenden und die angegebene Sicherheitskonfiguration nicht mit den Parametern der bereichsübergreifenden Vertrauensstellung konfiguriert ist, tritt ein Fehler auf. Weitere Informationen finden Sie unter [Kerberos-Einstellungen für Cluster](emr-kerberos-configure-settings.md#emr-kerberos-cluster-configuration).
## Schritt 3: Den Cluster-Primärknoten konfigurieren
Abhängig von den Anforderungen an Ihre Architektur und Implementierung ist möglicherweise eine zusätzliche Einrichtung auf dem Cluster erforderlich. Sie können dies nach dem Erstellen oder anhand der Schritte oder Bootstrap-Aktionen während des Erstellungsvorgangs erledigen.
Für jeden Kerberos-authentifizierten Benutzer, der mittels SSH eine Verbindung mit dem Cluster herstellt, müssen Sie sicherstellen, dass Linux-Konten erstellt werden, die dem Kerberos-Benutzer entsprechen. Wenn Benutzerprinzipale von einem Active-Directory-Domain-Controller als externes KDC oder über eine bereichsübergreifende Vertrauensstellung bereitgestellt werden, erstellt Amazon EMR automatisch Linux-Benutzerkonten. Wenn Active Directory nicht verwendet wird, müssen Sie Prinzipale für jeden Benutzer erstellen, der ihrem Linux-Benutzer entspricht. Weitere Informationen finden Sie unter [Konfiguration eines Amazon EMR-Clusters für Kerberos-authentifizierte HDFS-Benutzer und SSH-Verbindungen](emr-kerberos-configuration-users.md).
Jeder Benutzer muss zudem über ein HDFS-Benutzerverzeichnis in seinem Besitz verfügen, das Sie erstellen müssen. Darüber hinaus muss SSH mit GSSAPI konfiguriert werden, damit Verbindungen von über Kerberos authentifizierten Benutzern zulässig sind. GSSAPI muss auf dem Primärknoten aktiviert sein und die Client-SSH-Anwendung muss so konfiguriert werden, dass sie GSSAPI verwendet. Weitere Informationen finden Sie unter [Konfiguration eines Amazon EMR-Clusters für Kerberos-authentifizierte HDFS-Benutzer und SSH-Verbindungen](emr-kerberos-configuration-users.md).
# Sicherheitskonfiguration und Cluster-Einstellungen für Kerberos auf Amazon EMR
Wenn Sie einen durch Kerberos geschützten Cluster erstellen, geben Sie die Sicherheitskonfiguration zusammen mit den Kerberos-Attributen an, die spezifisch für den Cluster sind. Sie können eine Gruppe nicht ohne die andere angeben, sonst tritt ein Fehler auf.
Dieses Thema bietet eine Übersicht über die für Kerberos verfügbaren Konfigurationsparameter, wenn Sie eine Sicherheitskonfiguration und einen Cluster erstellen. Darüber hinaus werden CLI-Beispiele zum Erstellen von kompatiblen Sicherheitskonfigurationen und Clustern für gängige Architekturen bereitgestellt.
## Kerberos-Einstellungen für Sicherheitskonfigurationen
Sie können mithilfe der Amazon EMR-Konsole, der oder der EMR-API eine Sicherheitskonfiguration erstellen AWS CLI, die Kerberos-Attribute spezifiziert. Die Sicherheitskonfiguration kann auch andere Sicherheitsoptionen enthalten, wie beispielsweise die Verschlüsselung. Weitere Informationen finden Sie unter [Erstellen Sie eine Sicherheitskonfiguration mit der Amazon EMR-Konsole oder mit AWS CLI](emr-create-security-configuration.md).
Verwenden Sie die folgenden Referenzen, um die verfügbaren Sicherheitskonfigurationseinstellungen für die Kerberos-Architektur zu verstehen, die Sie auswählen. Die Amazon-EMR-Konsoleneinstellungen werden angezeigt. Informationen zu den entsprechenden CLI-Optionen finden Sie unter [Angeben von Kerberos-Einstellungen mit dem AWS CLI](emr-create-security-configuration.md#emr-kerberos-cli-parameters) oder [Beispiele für Konfigurationen](emr-kerberos-config-examples.md).
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/emr-kerberos-configure-settings.html)
## Kerberos-Einstellungen für Cluster
Sie können Kerberos-Einstellungen angeben, wenn Sie einen Cluster mithilfe der Amazon EMR-Konsole AWS CLI, der oder der EMR-API erstellen.
Verwenden Sie die folgenden Referenzen, um die verfügbaren Clusterkonfigurationseinstellungen für die Kerberos-Architektur zu verstehen, die Sie auswählen. Die Amazon-EMR-Konsoleneinstellungen werden angezeigt. Informationen zu den entsprechenden CLI-Optionen finden Sie unter [Beispiele für Konfigurationen](emr-kerberos-config-examples.md).
| Parameter | Description |
| --- | --- |
| Bereich | Der Kerberos-Bereichsname für den Cluster. Die Kerberos-Konvention ist, denselben Namen wie den Domain-Namen zu verwenden, aber in Großbuchstaben. Beispielsweise für die Domain `ec2.internal`mit `EC2.INTERNAL` als Bereichsnamen. |
| KDC-Administratorpasswort | Das im Cluster verwendete Passwort für `kadmin` oder `kadmin.local`. Dabei handelt es sich um Befehlszeilen-Schnittstellen zum Kerberos V5-Verwaltungssystem, das Kerberos-Prinzipale, Passwortrichtlinien und Keytabs für den Cluster verwaltet. |
| Prinzipal-Passwort für bereichsübergreifende Vertrauensstellungen (optional) | Erforderlich, wenn eine bereichsübergreifende Vertrauensstellung eingerichtet wird. Das Passwort für die bereichsübergreifende Vertrauensstellung, die über alle Bereiche hinweg identisch sein muss. Verwenden Sie ein sicheres Passwort. |
| Benutzer für die Verbindung mit der Active-Directory-Domain (optional) | Erforderlich bei Verwendung von Active Directory in einer bereichsübergreifenden Vertrauensstellung. Dies ist der Benutzeranmeldename eines Active-Directory-Kontos mit der Berechtigung, der Domain Computer hinzuzufügen. Amazon EMR verwendet diese Identität, um der Domain Cluster hinzuzufügen. Weitere Informationen finden Sie unter [Schritt 3: Konten zu der Domain für den EMR-Cluster hinzufügen](emr-kerberos-cross-realm.md#emr-kerberos-ad-users). |
| Passwort für die Verbindung mit der Active-Directory-Domain (optional) | Das Passwort für den Benutzer für die Verbindung mit der Active-Directory-Domain. Weitere Informationen finden Sie unter [Schritt 3: Konten zu der Domain für den EMR-Cluster hinzufügen](emr-kerberos-cross-realm.md#emr-kerberos-ad-users). |
# Beispiele für Konfigurationen
Die folgenden Beispiele veranschaulichen Sicherheitskonfigurationen und Clusterkonfigurationen für gängige Szenarien. AWS CLI Befehle werden der Kürze halber dargestellt.
## Lokales KDC
Mit den folgenden Befehlen erstellen Sie einen Cluster mit einem Cluster-spezifischen KDC, das auf dem Primärknoten ausgeführt wird. Eine zusätzliche Konfiguration auf dem Cluster ist erforderlich. Weitere Informationen finden Sie unter [Konfiguration eines Amazon EMR-Clusters für Kerberos-authentifizierte HDFS-Benutzer und SSH-Verbindungen](emr-kerberos-configuration-users.md).
**Sicherheitskonfiguration erstellen**
```
aws emr create-security-configuration --name LocalKDCSecurityConfig \
--security-configuration '{"AuthenticationConfiguration": \
{"KerberosConfiguration": {"Provider": "ClusterDedicatedKdc",\
"ClusterDedicatedKdcConfiguration": {"TicketLifetimeInHours": 24 }}}}'
```
**Erstellen eines Clusters**
```
aws emr create-cluster --release-label emr-7.12.0 \
--instance-count 3 --instance-type m5.xlarge \
--applications Name=Hadoop Name=Hive --ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=MyEC2Key \
--service-role EMR_DefaultRole \
--security-configuration LocalKDCSecurityConfig \
--kerberos-attributes Realm=EC2.INTERNAL,KdcAdminPassword=MyPassword
```
## Cluster-spezifisches KDC mit bereichsübergreifender Active-Directory-Vertrauensstellung
Mit den folgenden Befehlen erstellen Sie einen Cluster mit einem Cluster-spezifischen KDC, das auf dem Primärknoten mit einer bereichsübergreifenden Vertrauensstellung an einer Active-Directory-Domain ausgeführt wird. Zusätzliche Konfiguration auf dem Cluster und in Active Directory ist erforderlich. Weitere Informationen finden Sie unter [Tutorial: Konfigurieren einer bereichsübergreifenden Vertrauensstellung mit einer Active-Directory-Domain](emr-kerberos-cross-realm.md).
**Sicherheitskonfiguration erstellen**
```
aws emr create-security-configuration --name LocalKDCWithADTrustSecurityConfig \
--security-configuration '{"AuthenticationConfiguration": \
{"KerberosConfiguration": {"Provider": "ClusterDedicatedKdc", \
"ClusterDedicatedKdcConfiguration": {"TicketLifetimeInHours": 24, \
"CrossRealmTrustConfiguration": {"Realm":"AD.DOMAIN.COM", \
"Domain":"ad.domain.com", "AdminServer":"ad.domain.com", \
"KdcServer":"ad.domain.com"}}}}}'
```
**Erstellen eines Clusters**
```
aws emr create-cluster --release-label emr-7.12.0 \
--instance-count 3 --instance-type m5.xlarge --applications Name=Hadoop Name=Hive \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=MyEC2Key \
--service-role EMR_DefaultRole --security-configuration KDCWithADTrustSecurityConfig \
--kerberos-attributes Realm=EC2.INTERNAL,KdcAdminPassword=MyClusterKDCAdminPassword,\
ADDomainJoinUser=ADUserLogonName,ADDomainJoinPassword=ADUserPassword,\
CrossRealmTrustPrincipalPassword=MatchADTrustPassword
```
## Externes KDC auf einem anderen Cluster
Mit den folgenden Befehlen erstellen Sie einen Cluster, der auf ein Cluster-spezifisches KDC auf dem Primärknoten eines anderen Clusters verweist, um Prinzipale zu authentifizieren. Eine zusätzliche Konfiguration auf dem Cluster ist erforderlich. Weitere Informationen finden Sie unter [Konfiguration eines Amazon EMR-Clusters für Kerberos-authentifizierte HDFS-Benutzer und SSH-Verbindungen](emr-kerberos-configuration-users.md).
**Sicherheitskonfiguration erstellen**
```
aws emr create-security-configuration --name ExtKDCOnDifferentCluster \
--security-configuration '{"AuthenticationConfiguration": \
{"KerberosConfiguration": {"Provider": "ExternalKdc", \
"ExternalKdcConfiguration": {"KdcServerType": "Single", \
"AdminServer": "MasterDNSOfKDCMaster:749", \
"KdcServer": "MasterDNSOfKDCMaster:88"}}}}'
```
**Erstellen eines Clusters**
```
aws emr create-cluster --release-label emr-7.12.0 \
--instance-count 3 --instance-type m5.xlarge \
--applications Name=Hadoop Name=Hive \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=MyEC2Key \
--service-role EMR_DefaultRole --security-configuration ExtKDCOnDifferentCluster \
--kerberos-attributes Realm=EC2.INTERNAL,KdcAdminPassword=KDCOnMasterPassword
```
## Externes Cluster-KDC mit bereichsübergreifender Active-Directory-Vertrauensstellung
Mit den folgenden Befehlen erstellen Sie einen Cluster ohne KDC. Der Cluster verweist auf ein Cluster-spezifisches KDC, das auf dem Primärknoten eines anderen Clusters ausgeführt wird, um Prinzipale zu authentifizieren. Dieses KDC verfügt über eine bereichsübergreifende Vertrauensstellung mit einem Active-Directory-Domain-Controller. Eine zusätzliche Konfiguration auf dem Primärknoten mit dem KDC ist erforderlich. Weitere Informationen finden Sie unter [Tutorial: Konfigurieren einer bereichsübergreifenden Vertrauensstellung mit einer Active-Directory-Domain](emr-kerberos-cross-realm.md).
**Sicherheitskonfiguration erstellen**
```
aws emr create-security-configuration --name ExtKDCWithADIntegration \
--security-configuration '{"AuthenticationConfiguration": \
{"KerberosConfiguration": {"Provider": "ExternalKdc", \
"ExternalKdcConfiguration": {"KdcServerType": "Single", \
"AdminServer": "MasterDNSofClusterKDC:749", \
"KdcServer": "MasterDNSofClusterKDC.com:88", \
"AdIntegrationConfiguration": {"AdRealm":"AD.DOMAIN.COM", \
"AdDomain":"ad.domain.com", \
"AdServer":"ad.domain.com"}}}}}'
```
**Erstellen eines Clusters**
```
aws emr create-cluster --release-label emr-7.12.0 \
--instance-count 3 --instance-type m5.xlarge --applications Name=Hadoop Name=Hive \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=MyEC2Key \
--service-role EMR_DefaultRole --security-configuration ExtKDCWithADIntegration \
--kerberos-attributes Realm=EC2.INTERNAL,KdcAdminPassword=KDCOnMasterPassword,\
ADDomainJoinUser=MyPrivilegedADUserName,ADDomainJoinPassword=PasswordForADDomainJoinUser
```
# Konfiguration eines Amazon EMR-Clusters für Kerberos-authentifizierte HDFS-Benutzer und SSH-Verbindungen
Amazon EMR erstellt Kerberos-authentifizierten Clients für Anwendungen, die auf dem Cluster ausgeführt werden, z. B. der `hadoop`-Benutzer, `spark`-Benutzer und andere. Sie können auch Benutzer hinzufügen, die mit Kerberos für Cluster-Prozesse authentifiziert werden. Authentifizierte Benutzer können dann eine Verbindung mit dem Cluster mit ihren Kerberos-Anmeldeinformationen einrichten und mit den Anwendungen arbeiten. Damit sich ein Benutzer am Cluster authentifizieren kann, sind die folgenden Konfigurationen erforderlich:
+ Auf dem Cluster muss ein Linux-Konto vorhanden sein, das dem Kerberos-Prinzipal im KDC entspricht. Amazon EMR erledigt dies automatisch in Architekturen, die in Active Directory integriert sind.
+ Sie müssen ein HDFS-Benutzerverzeichnis auf dem Primärknoten für jeden Benutzer erstellen und dem Benutzer Berechtigungen für das Verzeichnis erteilen.
+ Sie müssen den SSH-Service konfigurieren, sodass GSSAPI auf dem Primärknoten aktiviert ist. Darüber hinaus müssen die Benutzer einen SSH-Client mit aktiviertem GSSAPI aufweisen.
## Hinzufügen von Linux-Benutzern und Kerberos-Prinzipalen zum Primärknoten
Wenn Sie Active Directory nicht verwenden, müssen Sie Linux-Konten auf dem Cluster-Primärknoten erstellen und Prinzipale für diese Linux-Benutzer am KDC hinzufügen. Dies umfasst einen Prinzipal im KDC für den Primärknoten. Zusätzlich zu den Benutzerprinzipalen erfordert das KDC, das auf dem Primärknoten ausgeführt wird, einen Prinzipal für den lokalen Host.
Wenn Ihre Architektur eine Active Directory-Integration beinhaltet, werden Linux-Benutzer und Prinzipale auf dem lokalen KDC ggf. automatisch erstellt. Sie können diesen Schritt überspringen. Weitere Informationen erhalten Sie unter [Bereichsübergreifende Vertrauensstellung](emr-kerberos-options.md#emr-kerberos-crossrealm-summary) und [Externes KDC – Cluster-KDC mit anderer bereichsübergreifender Active-Directory-Vertrauensstellung](emr-kerberos-options.md#emr-kerberos-extkdc-ad-trust-summary).
**Wichtig**
Das KDC geht zusammen mit der Prinzipaldatenbank verloren, wenn der Primärknoten beendet wird, weil der Primärknoten kurzlebigen Speicher verwendet. Wenn Sie Benutzer für SSH-Verbindungen erstellen, empfehlen wir, eine bereichsübergreifende Vertrauensstellung mit einem externen KDC einzurichten, das für hohe Verfügbarkeit konfiguriert ist. Wenn Sie Benutzer für SSH-Verbindungen mithilfe von Linux-Konten erstellen, automatisieren Sie alternativ den Kontoerstellungsprozess mithilfe von Bootstrap-Aktionen und -Skripts, sodass er wiederholt werden kann, wenn Sie einen neuen Cluster erstellen.
Das Übermitteln eines Schritts an das Cluster nach dem Erstellen oder beim Erstellen des Clusters ist die einfachste Möglichkeit zum Hinzufügen von Benutzern und KDC-Prinzipalen. Alternativ können Sie eine Verbindung mit dem Primärknoten unter Verwendung eines EC2-Schlüsselpaars als standardmäßiger `hadoop`-Benutzer einrichten, um die Befehle auszuführen. Weitere Informationen finden Sie unter [Stellen Sie mithilfe von SSH eine Connect zum primären Knoten des Amazon EMR-Clusters her](emr-connect-master-node-ssh.md).
Im folgenden Beispiel wird einem Cluster ein bereits vorhandenes Bash-Skript `configureCluster.sh` übergeben, das auf seine Cluster-ID verweist. Das Skript wird in Amazon S3 gespeichert.
```
aws emr add-steps --cluster-id \
--steps Type=CUSTOM_JAR,Name=CustomJAR,ActionOnFailure=CONTINUE,\
Jar=s3://region.elasticmapreduce/libs/script-runner/script-runner.jar,\
Args=["s3://amzn-s3-demo-bucket/configureCluster.sh"]
```
Das folgende Beispiel veranschaulicht den Inhalt des `configureCluster.sh`-Skripts. Das Skript wickelt zudem die Erstellung von HDFS-Benutzerverzeichnissen und die Aktivierung von GSSAPI für SSH ab, die in den folgenden Abschnitten erläutert werden.
```
#!/bin/bash
#Add a principal to the KDC for the primary node, using the primary node's returned host name
sudo kadmin.local -q "ktadd -k /etc/krb5.keytab host/`hostname -f`"
#Declare an associative array of user names and passwords to add
declare -A arr
arr=([lijuan]=pwd1 [marymajor]=pwd2 [richardroe]=pwd3)
for i in ${!arr[@]}; do
#Assign plain language variables for clarity
name=${i}
password=${arr[${i}]}
# Create a principal for each user in the primary node and require a new password on first logon
sudo kadmin.local -q "addprinc -pw $password +needchange $name"
#Add hdfs directory for each user
hdfs dfs -mkdir /user/$name
#Change owner of each user's hdfs directory to that user
hdfs dfs -chown $name:$name /user/$name
done
# Enable GSSAPI authentication for SSH and restart SSH service
sudo sed -i 's/^.*GSSAPIAuthentication.*$/GSSAPIAuthentication yes/' /etc/ssh/sshd_config
sudo sed -i 's/^.*GSSAPICleanupCredentials.*$/GSSAPICleanupCredentials yes/' /etc/ssh/sshd_config
sudo systemctl restart sshd
```
## Hinzufügen von Benutzer-HDFS-Verzeichnissen
Um Ihren Benutzern zu ermöglichen, sich beim Cluster anzumelden, um Hadoop-Jobs auszuführen, müssen Sie HDFS-Benutzerverzeichnisse für ihre Linux-Konten hinzufügen und jedem Benutzer das Eigentum an ihrem Verzeichnis erteilen.
Das Übermitteln eines Schritts an das Cluster nach dem Erstellen oder beim Erstellen des Clusters ist die einfachste Möglichkeit zum Erstellen von HDFS-Verzeichnissen. Alternativ könnten Sie eine Verbindung mit dem Primärknoten unter Verwendung eines EC2-Schlüsselpaars als standardmäßiger `hadoop`-Benutzer einrichten, um die Befehle auszuführen. Weitere Informationen finden Sie unter [Stellen Sie mithilfe von SSH eine Connect zum primären Knoten des Amazon EMR-Clusters her](emr-connect-master-node-ssh.md).
Im folgenden Beispiel wird einem Cluster ein bereits vorhandenes Bash-Skript `AddHDFSUsers.sh` übergeben, das auf seine Cluster-ID verweist. Das Skript wird in Amazon S3 gespeichert.
```
aws emr add-steps --cluster-id \
--steps Type=CUSTOM_JAR,Name=CustomJAR,ActionOnFailure=CONTINUE,\
Jar=s3://region.elasticmapreduce/libs/script-runner/script-runner.jar,Args=["s3://amzn-s3-demo-bucket/AddHDFSUsers.sh"]
```
Das folgende Beispiel veranschaulicht den Inhalt des `AddHDFSUsers.sh`-Skripts.
```
#!/bin/bash
# AddHDFSUsers.sh script
# Initialize an array of user names from AD, or Linux users created manually on the cluster
ADUSERS=("lijuan" "marymajor" "richardroe" "myusername")
# For each user listed, create an HDFS user directory
# and change ownership to the user
for username in ${ADUSERS[@]}; do
hdfs dfs -mkdir /user/$username
hdfs dfs -chown $username:$username /user/$username
done
```
## Aktivieren von GSSAPI für SSH
Damit für Kerberos authentifizierte Benutzer mithilfe von SSH eine Verbindung mit dem Primärknoten herstellen, muss für den SSH-Service die GSSAPI-Authentifizierung aktiviert sein. Führen Sie zum Aktivieren von GSSAPI die folgenden Befehle über die Befehlszeile des Primärknotens aus oder verwenden Sie einen Schritt zum Ausführen als Skript. Nachdem Sie SSH neu konfiguriert haben, müssen Sie den Service neu starten.
```
sudo sed -i 's/^.*GSSAPIAuthentication.*$/GSSAPIAuthentication yes/' /etc/ssh/sshd_config
sudo sed -i 's/^.*GSSAPICleanupCredentials.*$/GSSAPICleanupCredentials yes/' /etc/ssh/sshd_config
sudo systemctl restart sshd
```
# Verwenden von SSH zum Herstellen einer Verbindung zu kerberisierten Clustern mit Amazon EMR
Dieser Abschnitt zeigt die Schritte für einen über Kerberos authentifizierten Benutzer, um eine Verbindung mit dem Primärknoten eines EMR-Clusters herzustellen.
Auf jedem Computer, der für eine SSH-Verbindung verwendet wird, müssen SSH-Client- und Kerberos-Client-Anwendungen installiert sein. Linux-Computer enthalten diese höchstwahrscheinlich standardmäßig. OpenSSH wird beispielsweise bei den meisten Linux-, Unix- und MacOS-Betriebssystemen installiert. Sie können nach einem SSH-Client suchen, indem Sie in der Befehlszeile **ssh** eingeben. Wenn Ihr Computer den Befehl nicht erkennt, installieren Sie einen SSH-Client, um eine Verbindung mit dem Primärknoten herzustellen. Das OpenSSH-Projekt bietet eine kostenlose Implementierung der umfassenden Palette von SSH-Tools. Weitere Informationen finden Sie auf der [OpenSSH](http://www.openssh.org/)-Website. Windows-Benutzer können Anwendungen wie [PuTTY](http://www.chiark.greenend.org.uk/~sgtatham/putty/) als SSH-Client verwenden.
Weitere Informationen zu SSH-Verbindungen finden Sie unter [Eine Verbindung zu einem Amazon-EMR-Cluster herstellen](emr-connect-master-node.md).
SSH verwendet GSSAPI zum Authentifizieren von Kerberos-Clients und müssen die GSSAPI-Authentifizierung für den SSH-Service auf dem Cluster-Primärknoten aktivieren. Weitere Informationen finden Sie unter [Aktivieren von GSSAPI für SSH](emr-kerberos-configuration-users.md#emr-kerberos-ssh-config). SSH-Clients müssen auch GSSAPI verwenden.
*MasterPublicDNS*Verwenden Sie in den folgenden Beispielen den Wert, der für **Master Public DNS** auf der Registerkarte **Zusammenfassung** im Bereich Cluster-Details angezeigt wird — zum Beispiel. *ec2-11-222-33-44.compute-1.amazonaws.com*
## Voraussetzung für krb5.conf (nicht Active Directory)
Bei der Verwendung einer Konfiguration ohne Active-Directory-Integration muss zusätzlich zu den SSH-Client- und Kerberos-Client-Anwendungen jeder Client-Computer über eine Kopie der `/etc/krb5.conf`-Datei verfügen, die mit der `/etc/krb5.conf`-Datei auf dem Cluster-Primärknoten übereinstimmt.
**So kopieren Sie die krb5.conf-Datei**
1. Verwenden Sie SSH, um mithilfe eines EC2-Schlüsselpaars und des `hadoop`-Standardbenutzers eine Verbindung zum Primärknoten herzustellen, zum Beispiel `hadoop@MasterPublicDNS`. Detaillierte Anweisungen finden Sie unter [Eine Verbindung zu einem Amazon-EMR-Cluster herstellen](emr-connect-master-node.md).
1. Kopieren Sie vom Primärknoten die Inhalte der `/etc/krb5.conf`-Datei. Weitere Informationen finden Sie unter [Eine Verbindung zu einem Amazon-EMR-Cluster herstellen](emr-connect-master-node.md).
1. Erstellen Sie auf jedem Client-Computer, der eine Verbindung zum Cluster herstellt, eine identische `/etc/krb5.conf`-Datei basierend auf der Kopie, die Sie im vorigen Schritt erstellt haben.
## Verwenden von Kinit und SSH
Immer wenn ein Benutzer eine Verbindung von einem Client-Computer aus mithilfe von Kerberos-Anmeldeinformationen herstellt, muss der Benutzer zuerst Kerberos-Tickets für seinen Benutzer auf dem Client-Computer verlängern. Darüber hinaus muss der SSH-Client so konfiguriert werden, dass die GSSAPI-Authentifizierung verwendet wird.
**So verwenden Sie SSH zum Herstellen einer Verbindung mit einem durch Kerberos geschützten EMR-Cluster**
1. Verwenden Sie `kinit` zum Verlängern Ihres Kerberos-Tickets, wie im folgenden Beispiel gezeigt
```
kinit user1
```
1. Verwenden Sie einen `ssh`-Client zusammen mit dem Prinzipal, den Sie im Cluster-spezifischen KDC- oder Active Directory-Benutzernamen erstellt haben. Stellen Sie sicher, dass die GSSAPI-Authentifizierung aktiviert ist, wie in den folgenden Beispielen gezeigt.
**Beispiel: Linux-Benutzer**
Die Option `-K ` gibt die GSSAPI-Authentifizierung an.
```
ssh -K user1@MasterPublicDNS
```
**Beispiel: Windows-Benutzer (PuTTY)**
Stellen Sie sicher, dass die GSSAPI-Authentifizierungsoption für die Sitzung wie angezeigt aktiviert ist:
![\[PuTTY Configuration window showing GSSAPI authentication options and library preferences.\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/images/kerb-gssapi-putty.png)
# Tutorial: Konfiguration eines clusterspezifischen KDC mit Amazon EMR
Dieses Thema führt Sie durch die Erstellung eines Clusters mit einem cluster-spezifischen *Key Distribution Center (KDC)*, das manuelle Hinzufügen von Linux-Konten zu allen Clusterknoten, das Hinzufügen von Kerberos-Prinzipalen zum KDC auf dem Primärknoten und das Sicherstellen, dass auf den Client-Computern ein Kerberos-Client installiert ist.
Weitere Informationen zur Amazon-EMR-Unterstützung für Kerberos und KDC sowie Links zur MIT-Kerberos-Dokumentation finden Sie unter [Verwenden Sie Kerberos für die Authentifizierung mit Amazon EMR](emr-kerberos.md).
## Schritt 1: Den durch Kerberos geschützten Cluster erstellen
1. Erstellen Sie eine Sicherheitskonfiguration, die Kerberos aktiviert. Das folgende Beispiel zeigt einen `create-security-configuration` Befehl mit dem AWS CLI , der die Sicherheitskonfiguration als Inline-JSON-Struktur spezifiziert. Sie können auch auf eine lokal gespeicherte Datei verweisen.
```
aws emr create-security-configuration --name MyKerberosConfig \
--security-configuration '{"AuthenticationConfiguration": {"KerberosConfiguration":
{"Provider": "ClusterDedicatedKdc", "ClusterDedicatedKdcConfiguration": {"TicketLifetimeInHours": 24}}}}'
```
1. Erstellen Sie einen Cluster, der auf die Sicherheitskonfiguration verweist, Kerberos-Attribute für die Cluster einrichtet, und Linux-Konten unter Verwendung einer Bootstrap-Aktion hinzufügt. Das folgende Beispiel zeigt den Befehl `create-cluster `unter Verwendung der AWS CLI. Der Befehl bezieht sich auf die Sicherheitskonfiguration, die Sie oben erstellt haben, `MyKerberosConfig`. Er referenziert auch ein einfaches Skript `createlinuxusers.sh`, als Bootstrap-Aktion, das Sie erstellen und zu Amazon S3 hochladen, bevor Sie den Cluster erstellen.
```
aws emr create-cluster --name "MyKerberosCluster" \
--release-label emr-7.12.0 \
--instance-type m5.xlarge \
--instance-count 3 \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=MyEC2KeyPair \
--service-role EMR_DefaultRole \
--security-configuration MyKerberosConfig \
--applications Name=Hadoop Name=Hive Name=Oozie Name=Hue Name=HCatalog Name=Spark \
--kerberos-attributes Realm=EC2.INTERNAL,\
KdcAdminPassword=MyClusterKDCAdminPwd \
--bootstrap-actions Path=s3://amzn-s3-demo-bucket/createlinuxusers.sh
```
Dar folgende Code zeigt den Inhalt des `createlinuxusers.sh`-Skripts, das jedem Knoten im Cluster user1, user2 und user3 hinzufügt. Im nächsten Schritt fügen Sie diese Benutzer als KDC-Prinzipale hinzu.
```
#!/bin/bash
sudo adduser user1
sudo adduser user2
sudo adduser user3
```
## Schritt 2: Dem KDC Prinzipale hinzufügen, HDFS-Benutzerverzeichnisse erstellen und SSH konfigurieren
Das KDC, das auf dem Primärknoten ausgeführt wird, benötigt einen Prinzipal für den lokalen Host und für jeden Benutzer, den Sie auf dem Cluster erstellen. Sie können auch für jeden Benutzer HDFS-Verzeichnisse erstellen, wenn sie eine Verbindung mit dem Cluster einrichten und Hadoop-Aufträge ausführen müssen. Analog dazu konfigurieren Sie den SSH-Service, um eine GSSAPI-Authentifizierung zu aktivieren, die für Kerberos erforderlich ist. Nachdem Sie GSSAPI aktiviert haben, starten Sie den SSH-Service neu.
Die einfachste Möglichkeit dafür ist, dem Cluster ein Skript zu übergeben. Das folgende Beispiel übergibt dem Cluster ein bash-Skript `configurekdc.sh`, das Sie im vorherigen Schritt erstellt haben, wobei Sie die Cluster-ID angeben. Das Skript wird in Amazon S3 gespeichert. Alternativ können Sie eine Verbindung mit dem Primärknoten unter Verwendung eines EC2-Schlüsselpaars einrichten, um die Befehle auszuführen oder das Skript bei der Erstellung des Clusters übergeben.
```
aws emr add-steps --cluster-id --steps Type=CUSTOM_JAR,Name=CustomJAR,ActionOnFailure=CONTINUE,Jar=s3://myregion.elasticmapreduce/libs/script-runner/script-runner.jar,Args=["s3://amzn-s3-demo-bucket/configurekdc.sh"]
```
Das folgende Beispiel veranschaulicht den Inhalt des `configurekdc.sh`-Skripts.
```
#!/bin/bash
#Add a principal to the KDC for the primary node, using the primary node's returned host name
sudo kadmin.local -q "ktadd -k /etc/krb5.keytab host/`hostname -f`"
#Declare an associative array of user names and passwords to add
declare -A arr
arr=([user1]=pwd1 [user2]=pwd2 [user3]=pwd3)
for i in ${!arr[@]}; do
#Assign plain language variables for clarity
name=${i}
password=${arr[${i}]}
# Create principal for sshuser in the primary node and require a new password on first logon
sudo kadmin.local -q "addprinc -pw $password +needchange $name"
#Add user hdfs directory
hdfs dfs -mkdir /user/$name
#Change owner of user's hdfs directory to user
hdfs dfs -chown $name:$name /user/$name
done
# Enable GSSAPI authentication for SSH and restart SSH service
sudo sed -i 's/^.*GSSAPIAuthentication.*$/GSSAPIAuthentication yes/' /etc/ssh/sshd_config
sudo sed -i 's/^.*GSSAPICleanupCredentials.*$/GSSAPICleanupCredentials yes/' /etc/ssh/sshd_config
sudo systemctl restart sshd
```
Die Benutzer, die Sie hinzugefügt haben, sollten jetzt in der Lage sein, mittels SSH eine Verbindung zum Cluster herzustellen. Weitere Informationen finden Sie unter [Verwenden von SSH zum Herstellen einer Verbindung zu kerberisierten Clustern mit Amazon EMR](emr-kerberos-connect-ssh.md).
# Tutorial: Konfigurieren einer bereichsübergreifenden Vertrauensstellung mit einer Active-Directory-Domain
Wenn Sie eine bereichsübergreifende Vertrauensstellung einrichten, gestatten Sie Prinzipalen (normalerweise Benutzern) aus einem anderen Kerberos-Bereich, sich bei Anwendungskomponenten auf dem EMR-Cluster zu authentifizieren. Das dem Cluster zugeordnete *Schlüsselverteilungszentrum (Key Distribution Center, KDC)* baut mithilfe eines *realmübergreifenden Prinzipals*, das in beiden Systemen existiert, eine Vertrauensbeziehung zu einem anderen KDC auf. KDCs Der Name des Prinzipals und das Passwort stimmen genau überein.
Eine bereichsübergreifende Vertrauensstellung erfordert, dass die KDCs einander über das Netzwerk erreichen und gegenseitig ihre Domain-Namen auflösen. Die Schritte für die Einrichtung einer bereichsübergreifenden Vertrauensstellung mit einem Microsoft-AD-Domain-Controller, der als EC2-Instance ausgeführt wird, sind nachfolgend gezeigt, ebenso wie ein Beispiel für eine Netzwerkeinrichtung, das die erforderliche Konnektivität und die Auflösung des Domainnamens durchführt. Jede Netzwerkkonfiguration, die den erforderlichen Netzwerkverkehr zwischen den Geräten zulässt, ist zulässig. KDCs
Optional können Sie nach dem Einrichten einer bereichsübergreifenden Vertrauensstellung bei Active Directory mit einem KDC auf einem Cluster einen anderen Cluster mit einer anderen Sicherheitskonfiguration erstellen, um auf das KDC auf dem ersten Cluster als externes KDC zu verweisen. Ein Beispiel für die Einrichtung einer Sicherheitskonfiguration und eines Clusters finden Sie unter [Externes Cluster-KDC mit bereichsübergreifender Active-Directory-Vertrauensstellung](emr-kerberos-config-examples.md#emr-kerberos-example-extkdc-ad-trust).
Weitere Informationen zur Amazon-EMR-Unterstützung für Kerberos und KDC sowie Links zur MIT-Kerberos-Dokumentation finden Sie unter [Verwenden Sie Kerberos für die Authentifizierung mit Amazon EMR](emr-kerberos.md).
**Wichtig**
Amazon EMR unterstützt keine realmübergreifenden Vertrauensstellungen mit. AWS Directory Service for Microsoft Active Directory
[Schritt 1: Die VPC und das Subnetz einrichten](#emr-kerberos-ad-network)
[Schritt 2: Den Active-Directory-Domain-Controller starten und installieren](#emr-kerberos-ad-dc)
[Schritt 3: Konten zu der Domain für den EMR-Cluster hinzufügen](#emr-kerberos-ad-users)
[Schritt 4: Eine eingehende Vertrauensstellung auf dem Active-Directory-Domain-Controller konfigurieren](#emr-kerberos-ad-configure-trust)
[Schritt 5: DHCP-Optionsmenge verwenden, um den Active-Directory-Domain-Controller zu einem VPC-DNS-Server zu machen](#emr-kerberos-ad-DHCP)
[Schritt 6: Starten eines von Kerberos geschützten EMR Clusters](#emr-kerberos-ad-cluster)
[Schritt 7: HDFS-Benutzer erstellen und Berechtigungen für Active-Directory-Benutzerkonten in dem Cluster festlegen](#emr-kerberos-ad-hadoopuser)
## Schritt 1: Die VPC und das Subnetz einrichten
Die folgenden Schritten zeigen, wie eine VPC und ein Subnetz erstellt werden, sodass das Cluster-spezifische KDC den Active-Directory-Domain-Controller erreichen und seinen Domainnamen auflösen kann. In diesen Schritten wird die Auflösung des Domain-Namens durch Angabe des Active-Directory-Domain-Controllers als Domain-Namen-Server in der DHCP-Optionsmenge durchgeführt. Weitere Informationen finden Sie unter [Schritt 5: DHCP-Optionsmenge verwenden, um den Active-Directory-Domain-Controller zu einem VPC-DNS-Server zu machen](#emr-kerberos-ad-DHCP).
Das KDC und der Active-Directory-Domain-Controller müssen in der Lage sein, gegenseitig ihren Domainnamen aufzulösen. Dies gestattet Amazon EMR, der Domain Computer hinzuzufügen und automatisch entsprechende Linux-Konten und SSH-Parameter auf Cluster-Instances zu konfigurieren.
Wenn Amazon EMR den Domain-Namen nicht auflösen kann, können Sie unter Verwendung der IP-Adresse des Active-Directory-Domain-Controllers auf die Vertrauensstellung verweisen. Sie müssen jedoch manuell Linux-Konten hinzufügen, dem Cluster-spezifischen KDC entsprechende Prinzipale hinzufügen und SSH konfigurieren.
**Einrichten der VPC und des Subnetzes**
1. Erstellen Sie eine Amazon VPC mit einem einzelnen öffentlichen Subnetz. Weitere Informationen finden Sie unter [Schritt 1: Die VPC erstellen](https://docs.aws.amazon.com/AmazonVPC/latest/GettingStartedGuide/getting-started-ipv4.html#getting-started-create-vpc) im *Handbuch für die ersten Schritte mit Amazon VPC*.
**Wichtig**
Wenn Sie einen Microsoft Active Directory-Domänencontroller verwenden, wählen Sie einen CIDR-Block für den EMR-Cluster aus, sodass alle IPv4 Adressen weniger als neun Zeichen lang sind (z. B. 10.0.0.0/16). Dies liegt daran, dass die DNS-Namen von Clustercomputern verwendet werden, wenn die Computer dem Active Directory-Verzeichnis beitreten. AWS weist [DNS-Hostnamen](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-hostnames) anhand der IPv4 Adresse so zu, dass längere IP-Adressen zu DNS-Namen mit mehr als 15 Zeichen führen können. Für Active Directory gilt ein Limit von 15 Zeichen für die Registrierung der Namen der hinzugefügten Computer, und es kürzt längere Namen, was zu unvorhersehbaren Fehlern führen kann.
1. Entfernen Sie die Standard-DHCP-Optionsmenge, die der VPC zugeordnet ist. Weitere Informationen finden Sie unter [Ändern der VPC, um keine DHCP-Optionen zu verwenden](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html#DHCP_Use_No_Options). Später fügen Sie eine neue hinzu, die den Active-Directory-Domain-Controller als DNS-Server spezifiziert.
1. Vergewissern Sie sich, dass DNS-Support für die VPC aktiviert ist, dass DNS-Hostnamen und DNS-Auflösung beide aktiviert sind. Standardmäßig sind sie aktiviert. Weitere Informationen finden Sie unter [Aktualisieren der DNS-Unterstützung für Ihre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating).
1. Vergewissern Sie sich, dass Ihrer VPC ein Internet-Gateway zugeordnet ist. Dies ist die Standardeinstellung. Weitere Informationen finden Sie unter [Erstellen und Anfügen eines Internet-Gateways](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#Add_IGW_Attach_Gateway).
**Anmerkung**
In diesem Beispiel wird ein Internet-Gateway verwendet, weil Sie einen neuen Domain-Controller für den VPC einrichten. Für Ihre Anwendung ist möglicherweise kein Internet-Gateway erforderlich. Die einzige Voraussetzung ist, dass das Cluster-spezifische KDC auf den Active-Directory-Domain-Controller zugreifen kann.
1. Erstellen Sie eine benutzerdefinierte Routing-Tabelle, fügen Sie eine Route zum Internet-Gateway hinzu, und ordnen Sie ihn dann Ihrem Subnetz zu. Weitere Informationen finden Sie unter [Erstellen einer benutzerdefinierten Routing-Tabelle](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#Add_IGW_Routing).
1. Wenn Sie die EC2-Instance für den Domänencontroller starten, muss sie über eine statische öffentliche IPv4 Adresse verfügen, damit Sie über RDP eine Verbindung zu ihr herstellen können. Der einfachste Weg, dies zu tun, besteht darin, Ihr Subnetz so zu konfigurieren, dass öffentliche IPv4 Adressen automatisch zugewiesen werden. Dies ist nicht die Standardeinstellung, wenn ein Subnetz erstellt wird. Weitere Informationen finden Sie unter [Ändern des Attributs für die öffentliche IPv4 Adressierung Ihres Subnetzes](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip). Optional können Sie die Adresse zuweisen, wenn Sie die Instance starten. Weitere Informationen finden Sie unter [Zuweisen einer öffentlichen IPv4 Adresse beim Instance-Start](https://docs.aws.amazon.com/vpc/latest/userguide/using-instance-addressing.html#public-ip-addresses).
1. Wenn Sie fertig sind, notieren Sie sich Ihre VPC und Ihr IDs Subnetz. Sie benötigen sie später, wenn Sie den Active-Directory-Domain-Controller und den Cluster starten.
## Schritt 2: Den Active-Directory-Domain-Controller starten und installieren
1. So starten Sie eine EC2-Instance basierend auf der Microsoft Windows Server 2016 Basis-AMI. Wir empfehlen einen m4.xlarge oder einen besseren Instance-Typ. Weitere Informationen finden Sie unter [Launching an AWS Marketplace Instance](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/launch-marketplace-console.html) im *Amazon EC2 EC2-Benutzerhandbuch*.
1. Notieren Sie sich die Gruppen-ID der Sicherheitsgruppe, die der EC2-Instance zugeordnet ist. Sie benötigen sie für [Schritt 6: Starten eines von Kerberos geschützten EMR Clusters](#emr-kerberos-ad-cluster). Wir verwenden*sg-012xrlmdomain345*. Alternativ können Sie verschiedene Sicherheitsgruppen für den EMR-Cluster und diese Instance angeben, die den Datenverkehr zwischen ihnen zulässt. Weitere Informationen finden Sie unter [Amazon-EC2-Sicherheitsgruppen für Linux-Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html) im *Amazon-EC2-Benutzerhandbuch*.
1. Stellen Sie unter Verwendung von RDP eine Verbindung mit der EC2-Instance her. Weitere Informationen finden Sie unter [Herstellen einer Verbindung zu Ihrer Windows-Instance](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/connecting_to_windows_instance.html) im *Amazon EC2 EC2-Benutzerhandbuch*.
1. Starten Sie **Server Manager**, um die Domain-Services-Rolle von Active Directory auf dem Server zu installieren und zu konfigurieren. Machen Sie den Server zu einem Domain-Controller und weisen Sie einen Domain-Namen zu (wir verwenden in diesem Beispiel hier `ad.domain.com`). Notieren Sie den Domain-Namen, da Sie ihn später benötigen, wenn Sie die EMR-Sicherheitskonfiguration und den Cluster erstellen. Wenn Sie noch keine Erfahrung mit der Einrichtung von Active Directory haben, können Sie den Anweisungen in [So richten Sie Active Directory (AD) in Windows Server 2016 ein](https://ittutorials.net/microsoft/windows-server-2016/setting-up-active-directory-ad-in-windows-server-2016/) folgen.
Die Instance startet neu, wenn Sie fertig sind.
## Schritt 3: Konten zu der Domain für den EMR-Cluster hinzufügen
RDP zum Active-Directory-Domain-Controller zum Erstellen von Benutzerkonten in Active-Directory-Benutzern und -Computern für jeden Cluster-Benutzer. Weitere Informationen finden Sie unter [Erstellen eines Benutzerkontos in Active-Directory-Benutzern und -Computern](https://technet.microsoft.com/en-us/library/dd894463(v=ws.10).aspx) auf der Website *Microsoft Learn*. Notieren Sie den Wert für **User logon name (Benutzeranmeldename)** jedes Benutzers. Sie benötigen diese später, wenn Sie den Cluster konfigurieren.
Darüber hinaus erstellen Sie ein Konto mit ausreichenden Berechtigungen, um der Domain Computer hinzuzufügen. Sie geben dieses Konto an, wenn Sie einen Cluster erstellen. Amazon EMR verwendet es, um der Domain Cluster-Instances hinzuzufügen. Sie geben dieses Konto und sein Passwort in [Schritt 6: Starten eines von Kerberos geschützten EMR Clusters](#emr-kerberos-ad-cluster) an. Für die Delegation von Join-Berechtigungen des Computers an das Konto empfehlen wir das Erstellen einer Gruppe mit Join-Berechtigungen und die anschließende Zuweisung des Benutzers zu der Gruppe. Weitere Informationen finden Sie unter [Delegieren von Berechtigungen für den Verzeichniszugang](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_join_privileges.html) im *AWS Directory Service -Administratorhandbuch*.
## Schritt 4: Eine eingehende Vertrauensstellung auf dem Active-Directory-Domain-Controller konfigurieren
Die folgenden Beispielbefehle erstellen ein Vertrauensverhältnis in Active Directory. Dabei handelt es sich um eine unidirektionale eingehende, nicht transitive, Bereichsvertrauensstellung mit dem Cluster-spezifischen KDC. Das Beispiel, das wir für den Bereich des Clusters verwenden, ist `EC2.INTERNAL`. Ersetzen Sie das *KDC-FQDN* durch den **öffentlichen DNS-Namen**, der für den Amazon EMR-Primärknoten aufgeführt ist, der den KDC hostet. Der Parameter `passwordt` gibt das **cross-realm principal password (Passwort des bereichsübergreifenden Prinzipals)** an, das Sie beim Erstellen eines Clusters zusammen mit dem **realm (Bereich)** des Clusters angeben. Der Bereichsname wird von dem Standard-Domain-Namen `us-east-1` für den Cluster abgeleitet. Die `Domain` ist die Active-Directory-Domain, in der Sie die Vertrauensstellung erstellen. Sie wird gemäß Konvention in Kleinbuchstaben angegeben. Im Beispiel wird `ad.domain.com` verwendet.
Öffnen Sie die Windows-Eingabeaufforderung mit Administrator-Berechtigungen und geben Sie die folgenden Befehle zum Erstellen der Vertrauensstellung auf dem Active-Directory-Domain-Controller ein:
```
C:\Users\Administrator> ksetup /addkdc EC2.INTERNAL KDC-FQDN
C:\Users\Administrator> netdom trust EC2.INTERNAL /Domain:ad.domain.com /add /realm /passwordt:MyVeryStrongPassword
C:\Users\Administrator> ksetup /SetEncTypeAttr EC2.INTERNAL AES256-CTS-HMAC-SHA1-96
```
## Schritt 5: DHCP-Optionsmenge verwenden, um den Active-Directory-Domain-Controller zu einem VPC-DNS-Server zu machen
Nachdem der Active-Directory-Domain-Controller konfiguriert ist, müssen Sie die VPC so konfigurieren, dass er als Domain-Namenserver für die Namensauflösung in Ihrer VPC verwendet wird. Dazu ordnen Sie eine DHCP-Optionsmenge zu. Geben Sie einen Wert in **Domainname** als Domainnamen für Ihren Cluster ein, z. B. `ec2.internal`, wenn sich Ihr Cluster in us-east-1 befindet, oder `region.compute.internal` für andere Regionen. Für **Domainnamenserver** müssen Sie die IP-Adresse des Active Directory-Domänencontrollers (der vom Cluster aus erreichbar sein muss) als ersten Eintrag angeben, gefolgt von **AmazonProvidedDNS** (z. B. **AmazonProvidedDNS**). *xx.xx.xx.xx* Weitere Informationen finden Sie unter [Ändern von DHCP-Optionssätzen](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html#DHCPOptions).
## Schritt 6: Starten eines von Kerberos geschützten EMR Clusters
1. Erstellen Sie in Amazon EMR eine Sicherheitskonfiguration, die den Active-Directory-Domain-Controller angibt, den Sie in den vorherigen Schritten erstellt haben. Ein Beispielbefehl ist nachfolgend gezeigt. Ersetzen Sie die Domain `ad.domain.com` durch den Namen der Domain, die Sie in [Schritt 2: Den Active-Directory-Domain-Controller starten und installieren](#emr-kerberos-ad-dc) angegeben haben.
```
aws emr create-security-configuration --name MyKerberosConfig \
--security-configuration '{
"AuthenticationConfiguration": {
"KerberosConfiguration": {
"Provider": "ClusterDedicatedKdc",
"ClusterDedicatedKdcConfiguration": {
"TicketLifetimeInHours": 24,
"CrossRealmTrustConfiguration": {
"Realm": "AD.DOMAIN.COM",
"Domain": "ad.domain.com",
"AdminServer": "ad.domain.com",
"KdcServer": "ad.domain.com"
}
}
}
}
}'
```
1. Erstellen Sie den Cluster mit den folgenden Attributen:
+ Verwenden Sie die `--security-configuration`-Option, um die Sicherheitskonfiguration anzugeben, die Sie erstellt haben. Wir verwenden *MyKerberosConfig* im Beispiel.
+ Verwenden Sie die `SubnetId`-Eigenschaft der `--ec2-attributes option`, um das Subnetz anzugeben, das Sie in [Schritt 1: Die VPC und das Subnetz einrichten](#emr-kerberos-ad-network) erstellt haben. Wir verwenden *step1-subnet* im Beispiel.
+ Verwenden Sie die `AdditionalMasterSecurityGroups` und `AdditionalSlaveSecurityGroups` der `--ec2-attributes`-Option, um anzugeben, dass die Sicherheitsgruppe, die dem AD-Domain-Controller von [Schritt 2: Den Active-Directory-Domain-Controller starten und installieren](#emr-kerberos-ad-dc) zugeordnet ist, dem Cluster-Primärknoten sowie dem Core- und dem Aufgabenknoten zugeordnet ist. Wir verwenden *sg-012xrlmdomain345* im Beispiel.
Verwenden Sie `--kerberos-attributes`, um die folgenden Cluster-spezifischen Kerberos-Attribute anzugeben:
+ Den Bereich für den Cluster, den Sie bei der Einrichtung des Active-Directory-Domain-Controllers angegeben haben.
+ Das Prinzipal-Passwort der bereichsübergreifenden Vertrauensstellung, das Sie als `passwordt` in [Schritt 4: Eine eingehende Vertrauensstellung auf dem Active-Directory-Domain-Controller konfigurieren](#emr-kerberos-ad-configure-trust) angegeben haben.
+ Ein `KdcAdminPassword`, das Sie für die Verwaltung des Cluster-spezifischen KDC verwenden können.
+ Der Benutzeranmeldename und das Passwort des Active Directory-Kontos mit Computer-Join-Berechtigungen, die Sie in [Schritt 3: Konten zu der Domain für den EMR-Cluster hinzufügen](#emr-kerberos-ad-users) erstellt haben.
Das folgende Beispiel startet einen Cluster mit Schutz durch Kerberos.
```
aws emr create-cluster --name "MyKerberosCluster" \
--release-label emr-5.10.0 \
--instance-type m5.xlarge \
--instance-count 3 \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=MyEC2KeyPair,\
SubnetId=step1-subnet, AdditionalMasterSecurityGroups=sg-012xrlmdomain345,
AdditionalSlaveSecurityGroups=sg-012xrlmdomain345\
--service-role EMR_DefaultRole \
--security-configuration MyKerberosConfig \
--applications Name=Hadoop Name=Hive Name=Oozie Name=Hue Name=HCatalog Name=Spark \
--kerberos-attributes Realm=EC2.INTERNAL,\
KdcAdminPassword=MyClusterKDCAdminPwd,\
ADDomainJoinUser=ADUserLogonName,ADDomainJoinPassword=ADUserPassword,\
CrossRealmTrustPrincipalPassword=MatchADTrustPwd
```
## Schritt 7: HDFS-Benutzer erstellen und Berechtigungen für Active-Directory-Benutzerkonten in dem Cluster festlegen
Wenn Sie eine Vertrauensstellung mit Active Directory einrichten, erstellt Amazon EMR Linux-Benutzer auf dem Cluster für jedes Active Directory-Konto. Beispielsweise hat der Benutzeranmeldename `LiJuan` in Active Directory ein Linux-Benutzerkonto von `lijuan`. Active Directory-Benutzernamen können Großbuchstaben, aber Linux ignoriert die Groß-/Kleinschreibung von Active Directory.
Um Ihren Benutzern zu ermöglichen, sich beim Cluster anzumelden, um Hadoop-Jobs auszuführen, müssen Sie HDFS-Benutzerverzeichnisse für ihre Linux-Konten hinzufügen und jedem Benutzer das Eigentum an ihrem Verzeichnis erteilen. Zu diesem Zweck empfehlen wir, dass Sie ein Skript ausführen, das Sie in Amazon S3 als Cluster-Schritt gespeichert haben. Alternativ können Sie die Befehle aus dem folgenden Skript von der Befehlszeile auf dem Primärknoten aus ausführen. Verwenden Sie das EC2-Schlüsselpaar, das Sie beim Erstellen des Clusters angegeben haben, um eine Verbindung mit dem Primärknoten über SSH als Hadoop-Benutzer einzurichten. Weitere Informationen finden Sie unter [Verwenden Sie ein EC2-Schlüsselpaar für SSH-Anmeldeinformationen für Amazon EMR](emr-plan-access-ssh.md).
Führen Sie den folgenden Befehl aus, um dem Cluster, der ein Skript ausführt, einen Schritt hinzuzufügen*AddHDFSUsers.sh*.
```
aws emr add-steps --cluster-id \
--steps Type=CUSTOM_JAR,Name=CustomJAR,ActionOnFailure=CONTINUE,\
Jar=s3://region.elasticmapreduce/libs/script-runner/script-runner.jar,Args=["s3://amzn-s3-demo-bucket/AddHDFSUsers.sh"]
```
Der Inhalt der Datei *AddHDFSUsers.sh* lautet wie folgt.
```
#!/bin/bash
# AddHDFSUsers.sh script
# Initialize an array of user names from AD or Linux users and KDC principals created manually on the cluster
ADUSERS=("lijuan" "marymajor" "richardroe" "myusername")
# For each user listed, create an HDFS user directory
# and change ownership to the user
for username in ${ADUSERS[@]}; do
hdfs dfs -mkdir /user/$username
hdfs dfs -chown $username:$username /user/$username
done
```
### Hadoop-Gruppen zugeordnete Active-Directory-Gruppen
Amazon EMR verwendet den System Security Services Daemon (SSD), um Active Directory-Gruppen Hadoop-Gruppen zuzuordnen. Um die Gruppenzuordnungen nach der Anmeldung am Primärknoten zu bestätigen, wie in [Verwenden von SSH zum Herstellen einer Verbindung zu kerberisierten Clustern mit Amazon EMR](emr-kerberos-connect-ssh.md) beschrieben, können Sie den Befehl `hdfs groups` ausführen, um zu bestätigen, dass Active Directory-Gruppen, zu denen Ihr Active Directory-Konto gehört, Hadoop-Gruppen für die entsprechenden Hadoop-Benutzer auf dem Cluster zugeordnet wurden. Sie können auch die Gruppenzuordnungen anderer Benutzer überprüfen, indem Sie einen oder mehrere Benutzernamen im Befehl angeben, z. B. `hdfs groups lijuan`. Weitere Informationen finden Sie unter [Groups](https://hadoop.apache.org/docs/r2.7.1/hadoop-project-dist/hadoop-hdfs/HDFSCommands.html#groups) im [Apache HDFS Commands Guide](https://hadoop.apache.org/docs/r2.7.1/hadoop-project-dist/hadoop-hdfs/HDFSCommands.html).
# Active-Directory- oder LDAP-Server für die Authentifizierung mit Amazon EMR verwenden
Mit Amazon EMR Versionen 6.12.0 und höher können Sie auch das LDAP-over-SSL-Protokoll (LDAPS) verwenden, um einen Cluster zu starten, der sich nativ in Ihren Corporate-Identity-Server integriert. LDAP (Lightweight Directory Access Protocol) ist ein offenes, herstellerneutrales Anwendungsprotokoll, das auf Daten zugreift und diese verwaltet. LDAP wird häufig für die Benutzerauthentifizierung gegen Unternehmensidentitätsserver verwendet, die auf Anwendungen wie Active Directory (AD) und OpenLDAP gehostet werden. Mit dieser nativen Integration können Sie Ihren LDAP-Server verwenden, um Benutzer auf Amazon EMR zu authentifizieren.
Zu den Highlights der Amazon EMR LDAP-Integration gehören:
+ Amazon EMR konfiguriert die unterstützten Anwendungen so, dass sie sich in Ihrem Namen mit der LDAP-Authentifizierung authentifizieren.
+ Amazon EMR konfiguriert und verwaltet die Sicherheit für die unterstützten Anwendungen mit dem Kerberos-Protokoll. Sie müssen keine Befehle oder Skripte eingeben.
+ Sie erhalten eine detaillierte Zugriffskontrolle (FGAC) durch die Apache Ranger-Autorisierung für die Hive-Metastore-Datenbank und -Tabellen. Weitere Informationen finden Sie unter [Integrieren Sie Amazon EMR mit Apache Ranger](emr-ranger.md).
+ Wenn Sie LDAP-Anmeldeinformationen für den Zugriff auf einen Cluster benötigen, erhalten Sie eine detaillierte Zugriffskontrolle (FGAC) darüber, wer über SSH auf Ihre EMR-Cluster zugreifen kann.
Die folgenden Seiten bieten einen konzeptionellen Überblick, die Voraussetzungen und die Schritte zum Starten eines EMR-Clusters mit der Amazon-EMR-LDAP-Integration.
**Topics**
+ [Übersicht über LDAP mit Amazon EMR](ldap-overview.md)
+ [LDAP-Komponenten für Amazon EMR](ldap-components.md)
+ [Anwendungsunterstützung und Überlegungen zu LDAP für Amazon EMR](ldap-considerations.md)
+ [Konfiguration und Start eines EMR-Clusters mit LDAP](ldap-setup.md)
+ [Beispiele für die Verwendung von LDAP mit Amazon EMR](ldap-examples.md)
# Übersicht über LDAP mit Amazon EMR
Das Lightweight Directory Access Protocol (LDAP) ist ein Softwareprotokoll, mit dem Netzwerkadministratoren den Zugriff auf Daten verwalten und kontrollieren, indem sie Benutzer im Netzwerk eines Unternehmens authentifizieren. Das LDAP-Protokoll speichert Informationen in einer hierarchischen Verzeichnisstruktur. Weitere Informationen finden Sie unter [Basiskonzepte für LDAP](https://ldap.com/basic-ldap-concepts/) auf *LDAP.com.*
Innerhalb eines Unternehmensnetzwerks verwenden viele Anwendungen möglicherweise das LDAP-Protokoll, um Benutzer zu authentifizieren. Mit der Amazon EMR LDAP-Integration können EMR-Cluster nativ dasselbe LDAP-Protokoll mit einer zusätzlichen Sicherheitskonfiguration verwenden.
Es gibt zwei Hauptimplementierungen des LDAP-Protokolls, die Amazon EMR unterstützt: **Active Directory** und **OpenLDAP.** Andere Implementierungen sind zwar möglich, aber die meisten passen zu den gleichen Authentifizierungsprotokollen wie Active Directory oder OpenLDAP.
## Active Directory (AD)
Active Directory (AD) ist ein Verzeichnisservice von Microsoft für Windows-Domainnetzwerke. AD ist in den meisten Windows Server-Betriebssystemen enthalten und kann mit Clients über die Protokolle LDAP und LDAPS kommunizieren. Zur Authentifizierung versucht Amazon EMR, eine Benutzerbindung mit Ihrer AD-Instance mit dem User Principal Name (UPN – Benutzer-Prinzipal-Name) als definiertem Namen und Passwort herzustellen. Der UPN verwendet das Standardformat `username@domain_name`.
## OpenLDAP
OpenLDAP ist eine kostenlose Open-Source-Implementierung des LDAP-Protokolls. Zur Authentifizierung versucht Amazon EMR, eine Benutzerbindung mit Ihrer OpenLDAP-Instance mit dem vollständig qualifizierten Domainnamen (FQDN) als den definierten Namen und Passwort herzustellen. Der FQDN verwendet das Standardformat `username_attribute=username,LDAP_user_search_base`. In der Regel lautet der `username_attribute` Wert `uid`, und der `LDAP_user_search_base` Wert enthält die Attribute des Baums, der zum Benutzer führt. Beispiel, `ou=People,dc=example,dc=com`.
Andere kostenlose Open-Source-Implementierungen des LDAP-Protokolls folgen in der Regel einem ähnlichen FQDN wie OpenLDAP für die eindeutigen Namen ihrer Benutzer.
# LDAP-Komponenten für Amazon EMR
Sie können Ihren LDAP-Server verwenden, um sich mit Amazon EMR und allen Anwendungen, die der Benutzer direkt auf dem EMR-Cluster verwendet, über die folgenden Komponenten zu authentifizieren.
**Secret Agent**
Der *Secret Agent* ist ein Cluster-Prozess, der alle Benutzeranfragen authentifiziert. Der Secret Agent erstellt die Benutzerbindung an Ihren LDAP-Server im Namen der unterstützten Anwendungen auf dem EMR-Cluster. Der Secret-Agent wird unter Benutzer `emrsecretagent` ausgeführt und schreibt Protokolle in das Verzeichnis `/emr/secretagent/log`. Diese Protokolle enthalten Details zum Status der Authentifizierungsanfrage jedes Benutzers und zu allen Fehlern, die bei der Benutzerauthentifizierung auftreten können.
**System Security Services Daemon (SSSD)**
*SSSD* ist ein Daemon, der auf jedem Knoten eines LDAP-fähigen EMR-Clusters läuft. SSSD erstellt und verwaltet einen UNIX-Benutzer, um Ihre Remote-Unternehmensidentität mit jedem Knoten zu synchronisieren. Yarn-basierte Anwendungen wie Hive und Spark erfordern, dass auf jedem Knoten, der eine Abfrage für einen Benutzer ausführt, ein lokaler UNIX-Benutzer vorhanden ist.
# Anwendungsunterstützung und Überlegungen zu LDAP für Amazon EMR
In diesem Thema werden unterstützte Anwendungen, unterstützte Funktionen und nicht unterstützte Funktionen aufgeführt.
## Unterstützte Anwendungen mit LDAP für Amazon EMR
**Wichtig**
Die auf dieser Seite aufgeführten Anwendungen sind die einzigen Anwendungen, die Amazon EMR für LDAP unterstützt. Um die Clustersicherheit zu gewährleisten, können Sie nur LDAP-kompatible Anwendungen einbeziehen, wenn Sie einen EMR-Cluster mit aktiviertem LDAP erstellen. Wenn Sie versuchen, andere, nicht unterstützte Anwendungen zu installieren, lehnt Amazon EMR Ihre Anfrage für einen neuen Cluster ab.
Die Amazon-EMR-Versionen 6.12 und höher unterstützen die LDAP-Integration mit den folgenden Anwendungen:
+ Apache Livy
+ Apache Hive bis HiveServer 2 () HS2
+ Trino
+ Presto
+ Hue
Sie können auch die folgenden Anwendungen auf einem EMR-Cluster installieren und sie so konfigurieren, dass sie Ihren Sicherheitsanforderungen entsprechen:
+ Apache Spark
+ Apache Hadoop
## Unterstützte Features mit LDAP für Amazon EMR
Mit der LDAP-Integration können Sie die folgenden Amazon-EMR-Feature verwenden:
**Anmerkung**
Um die Sicherheit der LDAP-Anmeldeinformationen zu gewährleisten, müssen Sie die Verschlüsselung während der Übertragung verwenden, um den Datenfluss innerhalb und außerhalb des Clusters zu sichern. Weitere Informationen über Verschlüsselung während der Übertragung finden Sie unter [Verschlüsseln Sie Daten im Ruhezustand und bei der Übertragung mit Amazon EMR](emr-data-encryption.md).
+ Verschlüsselung während der Übertragung (erforderlich) und im Ruhestand
+ Instance-Gruppen, Instance-Flotten und Spot Instances
+ Neukonfiguration von Anwendungen auf einem laufenden Cluster
+ Serverseitige Verschlüsselung (SSE) von EMRFS
## Nicht unterstützte Funktionen
Berücksichtigen Sie die folgenden Einschränkungen, wenn Sie die Amazon- EMR-LDAP-Integration verwenden:
+ Amazon EMR deaktiviert Schritte für Cluster mit aktiviertem LDAP.
+ Amazon EMR unterstützt keine Runtime-Rollen und AWS Lake Formation Integrationen für Cluster mit aktiviertem LDAP.
+ Amazon EMR unterstützt LDAP mit StartTLS nicht.
+ Amazon EMR unterstützt keinen Hochverfügbarkeitsmodus (Cluster mit mehreren Primärknoten) für Cluster mit aktiviertem LDAP.
+ Sie können Bind-Anmeldeinformationen oder Zertifikate für Cluster mit aktiviertem LDAP nicht rotieren. Wenn eines dieser Felder rotiert wurde, empfehlen wir, einen neuen Cluster mit den aktualisierten Bindungsanmeldeinformationen oder Zertifikaten zu starten.
+ Bei LDAP müssen Sie exakte Suchbasen verwenden. Die LDAP-Benutzer- und Gruppensuchbasis unterstützt keine LDAP-Suchfilter.
# Konfiguration und Start eines EMR-Clusters mit LDAP
In diesem Abschnitt wird beschrieben, wie Sie Amazon EMR für die Verwendung mit der LDAP-Authentifizierung konfigurieren können.
**Topics**
+ [AWS Secrets Manager Berechtigungen zur Amazon EMR-Instance-Rolle hinzufügen](ldap-setup-asm.md)
+ [Erstellen Sie die Amazon-EMR-Sicherheitskonfiguration für die LDAP-Integration](ldap-setup-security.md)
+ [Starten Sie einen EMR-Cluster, der sich mit LDAP authentifiziert](ldap-setup-launch.md)
# AWS Secrets Manager Berechtigungen zur Amazon EMR-Instance-Rolle hinzufügen
Amazon EMR verwendet eine IAM-Servicerolle, um in Ihrem Namen Aktionen zur Bereitstellung und Verwaltung von Clustern durchzuführen. Die Servicerolle für EC2-Instance-Cluster (auch als *EC2-Instance-Profil für Amazon EMR* bezeichnet) ist eine spezielle Art von Servicerolle, die jeder EC2-Instance in einem Amazon-EMR-Cluster zugewiesen wird, wenn die Instance startet.
Um die Berechtigungen für einen EMR-Cluster für die Interaktion mit Amazon-S3-Daten und anderen AWS -Services zu definieren, definieren Sie ein benutzerdefiniertes Amazon EC2-Instance-Profil und nicht `EMR_EC2_DefaultRole`, wenn Sie Ihren Cluster starten. Weitere Informationen erhalten Sie unter [Servicerolle für EC2-Cluster-Instances (EC2-Instance-Profil)](emr-iam-role-for-ec2.md) und [Passen Sie IAM-Rollen mit Amazon EMR an](emr-iam-roles-custom.md).
Fügen Sie dem standardmäßigen EC2-Instance-Profil die folgenden Anweisungen hinzu, damit Amazon EMR Sitzungen taggen und auf die zugreifen kann, in denen AWS Secrets Manager LDAP-Zertifikate gespeichert sind.
```
{
"Sid": "AllowAssumeOfRolesAndTagging",
"Effect": "Allow",
"Action": ["sts:TagSession", "sts:AssumeRole"],
"Resource": [
"arn:aws:iam::111122223333:role/LDAP_DATA_ACCESS_ROLE_NAME",
"arn:aws:iam::111122223333:role/LDAP_USER_ACCESS_ROLE_NAME"
]
},
{
"Sid": "AllowSecretsRetrieval",
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": [
"arn:aws:secretsmanager:us-east-1:111122223333:secret:LDAP_SECRET_NAME*",
"arn:aws:secretsmanager:us-east-1:111122223333:secret:ADMIN_LDAP_SECRET_NAME*"
]
}
```
**Anmerkung**
Ihre Cluster-Anfragen schlagen fehl, wenn Sie bei der Festlegung von Secrets Manager-Berechtigungen das `*`-Platzhalterzeichen am Ende des geheimen Namens vergessen. Der Platzhalter steht für die geheimen Versionen.
Sie sollten den Geltungsbereich der AWS Secrets Manager Richtlinie auch auf die Zertifikate beschränken, die Ihr Cluster für die Bereitstellung von Instances benötigt.
# Erstellen Sie die Amazon-EMR-Sicherheitskonfiguration für die LDAP-Integration
Bevor Sie einen EMR-Cluster mit LDAP-Integration starten können, verwenden Sie die Schritte unter [Erstellen Sie eine Sicherheitskonfiguration mit der Amazon EMR-Konsole oder mit AWS CLI](emr-create-security-configuration.md), um eine Amazon-EMR-Sicherheitskonfiguration für den Cluster zu erstellen. Füllen Sie die folgenden Konfigurationen im `LDAPConfiguration` Block unter `AuthenticationConfiguration` oder in den entsprechenden Feldern im Abschnitt **Sicherheitskonfigurationen** der Amazon-EMR-Konsole aus:
**`EnableLDAPAuthentication`**
Konsolenoption: **Authentifizierungsprotokoll: LDAP**
Um die LDAP-Integration zu verwenden, setzen Sie diese Option auf `true` oder wählen Sie sie als Authentifizierungsprotokoll aus, wenn Sie einen Cluster in der Konsole erstellen. Standardmäßig ist `EnableLDAPAuthentication` `true` wenn Sie eine Sicherheitskonfiguration in der Amazon-EMR-Konsole erstellen.
**`LDAPServerURL`**
Konsolenoption: Standort des **LDAP-Servers**
Der Speicherort des LDAP-Servers einschließlich des Präfix: `ldaps://location_of_server`.
**`BindCertificateARN`**
Konsolenoption: **LDAP-SSL-Zertifikat**
Der AWS Secrets Manager ARN, der das Zertifikat zum Signieren des SSL-Zertifikats enthält, das der LDAP-Server verwendet. Wenn Ihr LDAP-Server von einer öffentlichen Zertifizierungsstelle (CA) signiert ist, können Sie einen AWS Secrets Manager ARN mit einer leeren Datei bereitstellen. Weitere Informationen zum Speichern Ihres Zertifikats in Secrets Manager finden Sie unter [Speichern Sie TLS-Zertifikate in AWS Secrets Manager](emr-ranger-tls-certificates.md).
**`BindCredentialsARN`**
Konsolenoption: Anmeldeinformationen: **LDAP-Serverbindung**
Ein AWS Secrets Manager ARN, der die Bindungsanmeldedaten für den LDAP-Administratorbenutzer enthält. Die Anmeldeinformationen werden als JSON-Objekt gespeichert. In diesem Geheimnis gibt es nur ein Schlüssel-Wert-Paar. Der Schlüssel in dem Paar ist der Benutzername und der Wert ist das Passwort. Beispiel, `{"uid=admin,cn=People,dc=example,dc=com": "AdminPassword1"}`. Dies ist ein optionales Feld, es sei denn, Sie aktivieren die SSH-Anmeldung für Ihren EMR-Cluster. In vielen Konfigurationen benötigen Active-Directory-Instances Bindungsanmeldeinformationen, damit SSSD Benutzer synchronisieren kann.
**`LDAPAccessFilter`**
Konsolenoption: **LDAP-Zugriffsfilter**
Gibt die Teilmenge der Objekte auf Ihrem LDAP-Server an, die sich authentifizieren können. Wenn Sie beispielsweise allen Benutzern mit der `posixAccount` Objektklasse auf Ihrem LDAP-Server Zugriff gewähren möchten, definieren Sie den Zugriffsfilter als `(objectClass=posixAccount)`.
**`LDAPUserSearchBase`**
Konsolenoption: **LDAP-Benutzersuchbasis**
Die Suchbasis, zu der Ihre Benutzer innerhalb Ihres LDAP-Servers gehören. Beispiel, `cn=People,dc=example,dc=com`.
**`LDAPGroupSearchBase`**
Konsolenoption: **LDAP-Gruppensuchbasis**
Die Suchbasis, zu der Ihre Benutzer innerhalb Ihres LDAP-Servers gehören. Beispiel, `cn=Groups,dc=example,dc=com`.
**`EnableSSHLogin`**
Konsolenoption: **SSH-Anmeldung**
Gibt an, ob die Kennwortauthentifizierung mit LDAP-Anmeldeinformationen zulässig ist oder nicht. Wir empfehlen nicht, dass Sie diese Option aktiviert lassen. Schlüsselpaare sind eine sicherere Route, um den Zugriff auf EMR-Cluster zu ermöglichen. Dieses Feld ist optional und standardmäßig auf `false` gesetzt.
**`LDAPServerType`**
Konsolenoption: **LDAP-Servertyp**
Gibt den Typ des LDAP-Servers an, mit dem Amazon EMR eine Verbindung herstellt. Unterstützte Optionen sind Active Directory und OpenLDAP. Andere LDAP-Servertypen funktionieren möglicherweise, aber Amazon EMR unterstützt offiziell keine anderen Servertypen. Weitere Informationen finden Sie unter [LDAP-Komponenten für Amazon EMR](ldap-components.md).
**`ActiveDirectoryConfigurations`**
Ein erforderlicher Unterblock für Sicherheitskonfigurationen, die den Active-Directory-Servertyp verwenden.
**`ADDomain`**
Konsolenoption: **Active-Directory-Domain**
Der Domainname, der zur Erstellung des Benutzerprinzipalnamens (UPN) für die Benutzerauthentifizierung mit Sicherheitskonfigurationen verwendet wurde, die den Active-Directory-Servertyp verwenden.
## Überlegungen zu Sicherheitskonfigurationen mit LDAP und Amazon EMR
+ Um eine Sicherheitskonfiguration mit Amazon-EMR-LDAP-Integration zu erstellen, müssen Sie die Verschlüsselung während der Übertragung verwenden. Informationen zur Verschlüsselung der Daten während der Übertragung finden Sie unter [Verschlüsseln Sie Daten im Ruhezustand und bei der Übertragung mit Amazon EMR](emr-data-encryption.md).
+ Sie können die Kerberos-Konfiguration nicht in derselben Sicherheitskonfiguration definieren. Amazon EMR stellt ein KDC bereit, das automatisch für dieses KDC reserviert ist, und verwaltet das Administratorkennwort für dieses KDC. Benutzer können nicht auf dieses Admin-Passwort zugreifen.
+ Sie können keine IAM-Laufzeitrollen AWS Lake Formation in derselben Sicherheitskonfiguration definieren.
+ Die `LDAPServerURL` muss das `ldaps://`-Protokoll in ihrem Wert enthalten.
+ Der `LDAPAccessFilter` darf nicht leer sein.
## Verwenden Sie LDAP mit der Apache-Ranger-Integration für Amazon EMR
Mit der LDAP-Integration für Amazon EMR können Sie die Integration mit Apache Ranger weiter ausbauen. Wenn Sie Ihre LDAP-Benutzer in Ranger abrufen, können Sie diese Benutzer dann einem Apache-Ranger-Richtlinien-Server zuordnen, um sie in Amazon EMR und andere Anwendungen zu integrieren. Definieren Sie dazu das `RangerConfiguration`-Feld in `AuthorizationConfiguration` der Sicherheitskonfiguration, das Sie mit Ihrem LDAP-Cluster verwenden. Weitere Informationen zum Festlegen der Sicherheitskonfiguration finden Sie unter [Erstellen einer EMR-Sicherheitskonfiguration](emr-ranger-security-config.md).
Wenn Sie LDAP mit Amazon EMR verwenden, müssen Sie `KerberosConfiguration` mit Amazon EMR keine Integration für Apache Ranger bereitstellen.
# Starten Sie einen EMR-Cluster, der sich mit LDAP authentifiziert
Führen Sie die folgenden Schritte aus, um einen EMR-Cluster mit LDAP oder Active Directory zu starten.
1. Einrichten Ihrer Umgebung:
+ Stellen Sie sicher, dass die Knoten in Ihrem EMR-Cluster mit Amazon S3 kommunizieren können und AWS Secrets Manager. Weitere Informationen dazu, wie Sie Ihre EC2-Instance-Profilrolle ändern können, um mit diesen Services zu kommunizieren, finden Sie unter [AWS Secrets Manager Berechtigungen zur Amazon EMR-Instance-Rolle hinzufügen](ldap-setup-asm.md).
+ Wenn Sie Ihren EMR-Cluster in einem privaten Subnetz ausführen möchten, sollten Sie Amazon VPC-Endpunkte oder Network Address Transalation (NAT) verwenden, um die VPC für die Kommunikation mit S3 AWS PrivateLink und Secrets Manager zu konfigurieren. Weitere Informationen finden Sie unter [AWS PrivateLink und VPC-Endpoints](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html) und [NAT-Instances](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html) im *Handbuch für die ersten Schritte mit Amazon VPC*.
+ Stellen Sie sicher, dass zwischen Ihrem EMR-Cluster und dem LDAP-Server eine Netzwerkverbindung besteht. Ihre EMR-Cluster müssen über das Netzwerk auf Ihren LDAP-Server zugreifen. Die Primär-, Kern- und Aufgabenknoten für den Cluster kommunizieren mit dem LDAP-Server, um Benutzerdaten zu synchronisieren. Wenn Ihr LDAP-Server auf Amazon EC2 läuft, aktualisieren Sie die EC2-Sicherheitsgruppe, um Datenverkehr vom EMR-Cluster zu akzeptieren. Weitere Informationen finden Sie unter [AWS Secrets Manager Berechtigungen zur Amazon EMR-Instance-Rolle hinzufügen](ldap-setup-asm.md).
1. Erstellen Sie eine Amazon-EMR-Sicherheitskonfiguration für die LDAP-Integration. Weitere Informationen finden Sie unter [Erstellen Sie die Amazon-EMR-Sicherheitskonfiguration für die LDAP-Integration](ldap-setup-security.md).
1. Nachdem Sie nun eingerichtet sind, gehen Sie wie unter [Starten eines Amazon-EMR-Clusters](emr-gs.md#emr-getting-started-launch-sample-cluster) beschrieben vor, um Ihren Cluster mit den folgenden Konfigurationen zu starten:
+ Wählen Sie Amazon EMR Version 6.12. oder höher aus. Es wird empfohlen, ein Upgrade auf die neueste Amazon-EMR-Version durchzuführen.
+ Geben Sie für Ihren Cluster nur Anwendungen an oder wählen Sie sie aus, die LDAP unterstützen. Eine Liste der LDAP-unterstützten Anwendungen mit Amazon EMR finden Sie unter [Anwendungsunterstützung und Überlegungen zu LDAP für Amazon EMR](ldap-considerations.md).
+ Verwenden Sie die Sicherheitskonfiguration, die Sie im vorherigen Schritt erstellt haben.
# Beispiele für die Verwendung von LDAP mit Amazon EMR
Sobald Sie [einen EMR-Cluster bereitgestellt haben, der die LDAP-Integration verwendet](ldap-setup-launch.md), können Sie Ihre LDAP-Anmeldeinformationen über den integrierten Authentifizierungsmechanismus für Benutzernamen und Passwörter für jede [unterstützte Anwendung](ldap-considerations.md#ldap-considerations-apps) bereitstellen. Diese Seite zeigt einige Beispiele.
## Verwendung der LDAP-Authentifizierung mit Apache Hive
**Example – Apache Hive**
Der folgende Beispielbefehl startet eine Apache Hive-Sitzung über 2 und Beeline: HiveServer
```
beeline -u "jdbc:hive2://$HOSTNAME:10000/default;ssl=true;sslTrustStore=$TRUSTSTORE_PATH;trustStorePassword=$TRUSTSTORE_PASS" -n LDAP_USERNAME -p LDAP_PASSWORD
```
## Verwendung der LDAP-Authentifizierung mit Apache Hive
**Example – Apache Livy**
Der folgende Beispielbefehl startet eine Livy-Sitzung über cURL. Ersetzen Sie `ENCODED-KEYPAIR` durch eine Base64-kodierte Zeichenfolge für `username:password`.
```
curl -X POST --data '{"proxyUser":"LDAP_USERNAME","kind": "pyspark"}' -H "Content-Type: application/json" -H "Authorization: Basic ENCODED-KEYPAIR" DNS_OF_PRIMARY_NODE:8998/sessions
```
## Verwenden der LDAP-Authentifizierung mit Presto
**Example – Presto**
Der folgende Beispielbefehl startet eine Presto-Sitzung über die Presto-CLI:
```
presto-cli --user "LDAP_USERNAME" --password --catalog hive
```
Nachdem Sie diesen Befehl ausgeführt haben, geben Sie das LDAP-Passwort an der Eingabeaufforderung ein.
## Verwenden der LDAP-Authentifizierung mit Trino
**Example – Trino**
Der folgende Beispielbefehl startet eine Presto-Sitzung über die Presto-CLI:
```
trino-cli --user "LDAP_USERNAME" --password --catalog hive
```
Nachdem Sie diesen Befehl ausgeführt haben, geben Sie das LDAP-Passwort an der Eingabeaufforderung ein.
## Verwenden der LDAP-Authentifizierung mit Hue
Sie können über einen SSH-Tunnel, den Sie auf dem Cluster erstellen, auf die Hue-Benutzeroberfläche zugreifen, oder Sie können einen Proxy-Server einrichten, der die Verbindung öffentlich an Hue überträgt. Da Hue standardmäßig nicht im HTTPS-Modus läuft, empfehlen wir die Verwendung einer zusätzlichen Verschlüsselungsebene, um sicherzustellen, dass die Kommunikation zwischen den Clients und der Hue-Benutzeroberfläche mit HTTPS verschlüsselt ist. Dadurch wird die Wahrscheinlichkeit verringert, dass Sie versehentlich Benutzeranmeldeinformationen im Klartext preisgeben.
Um die Hue-Benutzeroberfläche zu verwenden, öffnen Sie die Hue-Benutzeroberfläche in Ihrem Browser und geben Sie Ihren LDAP-Benutzernamen und das Passwort ein, um sich anzumelden. Wenn die Anmeldeinformationen korrekt sind, meldet Hue Sie an und verwendet Ihre Identität, um Sie bei allen unterstützten Anwendungen zu authentifizieren.
## Verwendung von SSH für die Passwortauthentifizierung und Kerberos-Tickets für andere Anwendungen
**Wichtig**
Wir empfehlen nicht, die Passwortauthentifizierung für SSH in einen EMR-Cluster zu verwenden.
Sie können Ihre LDAP-Anmeldeinformationen verwenden, um eine SSH-Verbindung zu einem EMR-Cluster herzustellen. Stellen Sie dazu die `EnableSSHLogin`-Konfiguration in der Amazon-EMR-Sicherheitskonfiguration, die Sie zum Starten des Clusters verwenden, auf `true` ein. Verwenden Sie dann den folgenden Befehl, um per SSH auf den Cluster zuzugreifen, sobald dieser gestartet wurde:
```
ssh username@EMR_PRIMARY_DNS_NAME
```
Nachdem Sie diesen Befehl ausgeführt haben, geben Sie das LDAP-Passwort an der Eingabeaufforderung ein.
Amazon EMR enthält ein Cluster-Skript, das es Benutzern ermöglicht, eine Kerberos-Keytab-Datei und ein Ticket für die Verwendung mit unterstützten Anwendungen zu generieren, die LDAP-Anmeldeinformationen nicht direkt akzeptieren. Einige dieser Anwendungen umfassen `spark-submit` Spark SQL und. PySpark
Führen Sie `ldap-kinit` aus und befolgen Sie die Eingabeaufforderungen. Wenn die Authentifizierung erfolgreich ist, wird die Kerberos-Keytab-Datei mit einem gültigen Kerberos-Ticket in Ihrem Home-Verzeichnis angezeigt. Verwenden Sie das Kerberos-Ticket, um Anwendungen wie in jeder Kerberized-Umgebung auszuführen.
# Integrieren Sie Amazon EMR mit AWS IAM Identity Center
Mit Amazon EMR-Versionen 6.15.0 und höher können Sie Identitäten von verwenden, um sich bei einem Amazon AWS IAM Identity Center EMR-Cluster zu authentifizieren. Die folgenden Abschnitte bieten einen konzeptionellen Überblick, die Voraussetzungen und die Schritte zum Starten eines EMR-Clusters mit der Identity-Center-Integration.
**Topics**
+ [-Übersicht](#emr-idc-overview)
+ [Features und Vorteile](#emr-idc-features)
+ [Erste Schritte mit AWS IAM Identity Center Amazon EMR](emr-idc-start.md)
+ [Benutzersitzungen im Hintergrund](user-background-sessions.md)
+ [Überlegungen und Einschränkungen für Amazon EMR mit Identity-Center-Integration](emr-idc-considerations.md)
## -Übersicht
[Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) ist der empfohlene Ansatz für die Authentifizierung und Autorisierung von Mitarbeitern AWS für Unternehmen jeder Größe und Art. Mit Identity Center können Sie Benutzeridentitäten in Ihrer vorhandenen Identitätsquelle AWS, einschließlich Microsoft Active Directory, Okta, Ping Identity, Google Workspace und Microsoft Entra ID (ehemals Azure AD) JumpCloud, erstellen und verwalten oder eine Verbindung zu Ihrer vorhandenen Identitätsquelle herstellen.
[Die Weitergabe vertrauenswürdiger Identitäten](https://docs.aws.amazon.com//singlesignon/latest/userguide/trustedidentitypropagation-overview.html) ist eine AWS IAM Identity Center Funktion, mit der Administratoren von Connected den Zugriff auf Servicedaten gewähren und prüfen AWS-Services können. Der Zugriff auf diese Daten basiert auf Benutzerattributen wie Gruppenzuordnungen. Die Einrichtung der Verbreitung vertrauenswürdiger Identitäten erfordert die Zusammenarbeit zwischen den Administratoren von Connected AWS-Services und den IAM Identity Center-Administratoren. Weitere Informationen finden Sie unter [Voraussetzungen und Überlegungen](https://docs.aws.amazon.com//singlesignon/latest/userguide/trustedidentitypropagation-overall-prerequisites.html).
## Features und Vorteile
Die Integration von Amazon EMR in IAM Identity Center bietet die folgenden Vorteile:
+ Amazon EMR stellt Anmeldeinformationen bereit, um Ihre Identity-Center-Identität an einen EMR-Cluster weiterzuleiten.
+ Amazon EMR konfiguriert alle unterstützten Anwendungen für die Authentifizierung mit den Cluster-Anmeldeinformationen.
+ Amazon EMR konfiguriert und verwaltet die Sicherheit für die unterstützten Anwendungen mit dem Kerberos-Protokoll und ohne dass Befehle oder Skripts von Ihnen erforderlich sind.
+ Die Möglichkeit, die Amazon-S3-Autorisierung auf Präfixebene mit Identity-Center-Identitäten auf von S3 Access Grants verwalteten S3-Präfixen durchzusetzen.
+ Die Möglichkeit, die Autorisierung auf Tabellenebene mit Identity Center-Identitäten für AWS Lake Formation verwaltete AWS Glue-Tabellen durchzusetzen.
# Erste Schritte mit AWS IAM Identity Center Amazon EMR
Dieser Abschnitt hilft Ihnen bei der Konfiguration von Amazon EMR für die Integration mit AWS IAM Identity Center.
**Topics**
+ [Eine Identity-Center-Instance erstellen](#emr-idc-start-instance)
+ [Eine IAM-Rolle für Identity Center erstellen](#emr-idc-start-role)
+ [Fügen Sie Berechtigungen für Dienste hinzu, die nicht in IAM Identity Center integriert sind](#emr-idc-start-securityconfig-nonidc)
+ [Eine Identity-Center-fähige Sicherheitskonfiguration erstellen](#emr-idc-start-securityconfig)
+ [Einen Identity-Center-fähigen Cluster erstellen und starten](#emr-idc-cluster)
+ [Lake Formation für einen IAM-Identity-Center-aktivierten EMR-Cluster konfigurieren](emr-idc-lf.md)
+ [Mit S3 Access Grants auf einem IAM-Identity-Center-fähigen EMR-Cluster arbeiten](emr-idc-s3ag.md)
**Anmerkung**
Um die Identity Center-Integration mit EMR, Lake Formation oder S3 nutzen zu können, müssen Access Grants aktiviert sein. Sie können auch beide verwenden. Wenn keines der beiden aktiviert ist, wird die Identity Center-Integration nicht unterstützt.
## Eine Identity-Center-Instance erstellen
Wenn Sie noch keine haben, erstellen Sie eine Identity-Center-Instance in der AWS-Region , in der Sie Ihren EMR-Cluster starten möchten. Eine Identity-Center-Instance kann nur in einer einzigen Region für ein AWS-Konto existieren.
Verwenden Sie den folgenden AWS CLI Befehl, um eine neue Instanz mit dem Namen zu erstellen`MyInstance`:
```
aws sso-admin create-instance --name MyInstance
```
## Eine IAM-Rolle für Identity Center erstellen
Um Amazon EMR zu integrieren AWS IAM Identity Center, erstellen Sie eine IAM-Rolle, die sich über den EMR-Cluster bei Identity Center authentifiziert. Amazon EMR verwendet im Hintergrund SigV4-Anmeldeinformationen, um die Identity-Center-Identität an nachgelagerte Services weiterzuleiten, wie z. B. AWS Lake Formation. Ihre Rolle sollte auch über die entsprechenden Berechtigungen zum Aufrufen der nachgelagerten Services verfügen.
Verwenden Sie die folgende Berechtigungsrichtlinie zum Erstellen der Rolle:
```
{
"Statement": [
{
"Sid": "IdCPermissions",
"Effect": "Allow",
"Action": [
"sso-oauth:*"
],
"Resource": "*"
},
{
"Sid": "GlueandLakePermissions",
"Effect": "Allow",
"Action": [
"glue:*",
"lakeformation:GetDataAccess"
],
"Resource": "*"
},
{
"Sid": "AccessGrantsPermissions",
"Effect": "Allow",
"Action": [
"s3:GetDataAccess",
"s3:GetAccessGrantsInstanceForPrefix"
],
"Resource": "*"
}
]
}
```
Die Vertrauensrichtlinie für diese Rolle ermöglicht es der InstanceProfile-Rolle, sie die Rolle übernehmen zu lassen.
```
{
"Sid": "AssumeRole",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::12345678912:role/EMR_EC2_DefaultRole"
},
"Action": [
"sts:AssumeRole",
"sts:SetContext"
]
}
```
Wenn die Rolle keine vertrauenswürdigen Anmeldeinformationen hat und auf eine durch Lake Formation geschützte Tabelle zugreift, setzt Amazon EMR den Wert `principalId` der angenommenen Rolle automatisch auf. `userID-untrusted` Im Folgenden finden Sie einen Auszug aus einem Ereignis, das den anzeigt. CloudTrail `principalId`
```
{
"eventVersion": "1.09",
"userIdentity": {
"type": "AssumedRole",
"principalId": "ABCDEFGH1JKLMNO2PQR3TU:5000-untrusted",
"arn": "arn:aws:sts::123456789012:assumed-role/EMR_TIP/5000-untrusted",
"accountId": "123456789012",
"accessKeyId": "ABCDEFGH1IJKLMNOPQ7R3"
...
```
## Fügen Sie Berechtigungen für Dienste hinzu, die nicht in IAM Identity Center integriert sind
AWS Anmeldeinformationen, die Trusted Identity Propagation die in der IAM-Rolle definierten IAM-Richtlinien für alle Aufrufe von Diensten verwenden, die nicht in IAM Identity Center integriert sind. Dazu gehören beispielsweise die. AWS Key Management Service Ihre Rolle sollte auch alle IAM-Berechtigungen für solche Dienste definieren, auf die Sie beispielsweise AWS Key Management Service zugreifen möchten. Zu den derzeit unterstützten integrierten Diensten von IAM Identity Center gehören AWS Lake Formation Amazon S3 Access Grants.
Weitere Informationen zu Trusted Identity Propagation finden Sie unter [Trusted Identity Propagation zwischen Anwendungen](https://docs.aws.amazon.com/singlesignon/latest/userguide/trustedidentitypropagation.html).
## Eine Identity-Center-fähige Sicherheitskonfiguration erstellen
Um einen EMR-Cluster mit IAM-Identity-Center-Integration zu starten, verwenden Sie den folgenden Beispielbefehl, um eine Amazon-EMR-Sicherheitskonfiguration zu erstellen, für die Identity Center aktiviert ist. Jede Konfiguration wird im Folgenden erklärt.
```
aws emr create-security-configuration --name "IdentityCenterConfiguration-with-lf-accessgrants" --region "us-west-2" --security-configuration '{
"AuthenticationConfiguration":{
"IdentityCenterConfiguration":{
"EnableIdentityCenter":true,
"IdentityCenterApplicationAssigmentRequired":false,
"IdentityCenterInstanceARN": "arn:aws:sso:::instance/ssoins-123xxxxxxxxxx789"
}
},
"AuthorizationConfiguration": {
"LakeFormationConfiguration": {
"AuthorizedSessionTagValue": "Amazon EMR"
},
"IAMConfiguration": {
"EnableApplicationScopedIAMRole": true,
"ApplicationScopedIAMRoleConfiguration": {
"PropagateSourceIdentity": true
}
}
},
"EncryptionConfiguration": {
"EnableInTransitEncryption": true,
"EnableAtRestEncryption": false,
"InTransitEncryptionConfiguration": {
"TLSCertificateConfiguration": {
"CertificateProviderType": "PEM",
"S3Object": "s3://amzn-s3-demo-bucket/cert/my-certs.zip"
}
}
}
}'
```
+ **`EnableIdentityCenter`** – (erforderlich) Aktiviert die Identity-Center-Integration.
+ **`IdentityCenterInstanceARN`**— (optional) Der ARN der Identity Center-Instanz. Wenn dies nicht enthalten ist, wird der bestehende ARN der IAM Identity Center-Instanz als Teil des Konfigurationsschritts gesucht.
+ **`IAMRoleForEMRIdentityCenterApplicationARN`** – (erforderlich) Die IAM-Rolle, die Identity-Center-Token aus dem Cluster bezieht.
+ **`IdentityCenterApplicationAssignmentRequired `** – (boolean) Legt fest, ob für die Nutzung der Identity-Center-Anwendung eine Zuweisung erforderlich ist. Dies ist ein optionales Feld. Wenn kein Wert angegeben wird, ist `false` der Standardwert.
+ **`AuthorizationConfiguration`/`LakeFormationConfiguration`**— Konfigurieren Sie optional die Autorisierung:
+ **`IAMConfiguration`**— Ermöglicht die Verwendung der Funktion EMR Runtimes Roles zusätzlich zu Ihrer TIP-Identität. Wenn Sie diese Konfiguration aktivieren, müssen Sie (oder der AWS Anrufer-Service) bei jedem Aufruf der EMR Steps oder EMR eine IAM-Laufzeitrolle angeben. `GetClusterSessionCredentials` APIs Wenn der EMR-Cluster mit SageMaker Unified Studio verwendet wird, ist diese Option erforderlich, wenn Trusted Identity Propagation ebenfalls aktiviert ist.
+ **`EnableLakeFormation`** – Aktivieren Sie die Lake-Formation-Autorisierung auf dem Cluster.
Um die Identity-Center-Integration mit Amazon EMR zu aktivieren, müssen Sie `EncryptionConfiguration` und `IntransitEncryptionConfiguration` angeben.
## Einen Identity-Center-fähigen Cluster erstellen und starten
Nachdem Sie nun die IAM-Rolle eingerichtet haben, die sich bei Identity Center authentifiziert, und eine Amazon-EMR-Sicherheitskonfiguration erstellt haben, für die Identity Center aktiviert ist, können Sie Ihren identitätsbewussten Cluster erstellen und starten. Schritte zum Starten Ihres Clusters mit der erforderlichen Sicherheitskonfiguration finden Sie unter [Geben Sie eine Sicherheitskonfiguration für einen Amazon EMR-Cluster an](emr-specify-security-configuration.md).
In den folgenden Abschnitten wird beschrieben, wie Sie Ihren Identity Center-fähigen Cluster mit Sicherheitsoptionen konfigurieren, die Amazon EMR unterstützt:
+ [Mit S3 Access Grants auf einem IAM-Identity-Center-fähigen EMR-Cluster arbeiten](emr-idc-s3ag.md)
+ [Lake Formation für einen IAM-Identity-Center-aktivierten EMR-Cluster konfigurieren](emr-idc-lf.md)
# Lake Formation für einen IAM-Identity-Center-aktivierten EMR-Cluster konfigurieren
Sie können die Integration in [AWS Lake Formation](https://docs.aws.amazon.com/lake-formation/latest/dg/)Ihren AWS IAM Identity Center aktivierten EMR-Cluster durchführen.
Stellen Sie zunächst sicher, dass Sie eine Identity-Center-Instance in derselben Region wie Ihr Cluster eingerichtet haben. Weitere Informationen finden Sie unter [Eine Identity-Center-Instance erstellen](emr-idc-start.md#emr-idc-start-instance). Sie finden den Instance-ARN in der IAM-Identity-Center-Konsole, wenn Sie die Instance-Details anzeigen, oder über den folgenden Befehl, mit dem Details für all Ihre Instances über die CLI angezeigt werden:
```
aws sso-admin list-instances
```
Verwenden Sie dann den ARN und Ihre AWS Konto-ID mit dem folgenden Befehl, um Lake Formation so zu konfigurieren, dass es mit IAM Identity Center kompatibel ist:
```
aws lakeformation create-lake-formation-identity-center-configuration --cli-input-json file://create-lake-fromation-idc-config.json
json input:
{
"CatalogId": "account-id/org-account-id",
"InstanceArn": "identity-center-instance-arn"
}
```
Rufen Sie jetzt `put-data-lake-settings` auf und aktivieren Sie `AllowFullTableExternalDataAccess` mit Lake Formation:
```
aws lakeformation put-data-lake-settings --cli-input-json file://put-data-lake-settings.json
json input:
{
"DataLakeSettings": {
"DataLakeAdmins": [
{
"DataLakePrincipalIdentifier": "admin-ARN"
}
],
"CreateDatabaseDefaultPermissions": [...],
"CreateTableDefaultPermissions": [...],
"AllowExternalDataFiltering": true,
"AllowFullTableExternalDataAccess": true
}
}
```
Erteilen Sie abschließend dem Identity-ARN für den Benutzer, der auf den EMR-Cluster zugreift, vollständige Tabellenberechtigungen. Der ARN enthält die Benutzer-ID von Identity Center. Navigieren Sie in der Konsole zu Identity Center, wählen Sie **Users** (Benutzer) und dann den Benutzer aus, um dessen **allgemeine Informationseinstellungen** anzuzeigen.
Kopieren Sie die Benutzer-ID und fügen Sie sie für `user-id` in den folgenden ARN ein:
```
arn:aws:identitystore:::user/user-id
```
**Anmerkung**
Abfragen auf dem EMR-Cluster funktionieren nur, wenn die IAM-Identity-Center-Identität vollen Tabellenzugriff auf die geschützte Lake-Formation-Tabelle hat. Wenn die Identität keinen vollständigen Tabellenzugriff hat, schlägt die Abfrage fehl.
Verwenden Sie den folgenden Befehl, um dem Benutzer vollen Tabellenzugriff zu gewähren:
```
aws lakeformation grant-permissions --cli-input-json file://grantpermissions.json
json input:
{
"Principal": {
"DataLakePrincipalIdentifier": "arn:aws:identitystore:::user/user-id"
},
"Resource": {
"Table": {
"DatabaseName": "tip_db",
"Name": "tip_table"
}
},
"Permissions": [
"ALL"
],
"PermissionsWithGrantOption": [
"ALL"
]
}
```
## Hinzufügen des Anwendungs-ARN zu IDC für die Integration von Lake Formation
Um Lake Formation Formation-fähige Ressourcen abzufragen, muss der Anwendungs-ARN der IDC-Anwendung hinzugefügt werden. Führen Sie dazu die folgenden Schritte aus:
1. Wählen Sie auf der Konsole **AWS Lake Formation** aus.
1. Wählen Sie die **IAM Identity Center-Integration** und die **Lake Formation Formation-Anwendungsintegration** aus, indem Sie den Anwendungs-ARN abgleichen. Der ARN wird in der **Anwendungs-ID-Liste** angezeigt.
# Mit S3 Access Grants auf einem IAM-Identity-Center-fähigen EMR-Cluster arbeiten
Sie können [S3 Access Grants](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-grants.html) in Ihren AWS IAM Identity Center aktivierten EMR-Cluster integrieren.
Verwenden Sie S3 Access Grants, um den Zugriff auf Ihre Datensätze von Clustern aus zu autorisieren, die Identity Center verwenden. Erstellen Sie Zuweisungen, um die Berechtigungen zu erweitern, die Sie für IAM-Benutzer, -Gruppen, -Rollen oder für ein Unternehmensverzeichnis festlegen. Weitere Informationen finden Sie unter [Verwenden von S3 Access Grants mit Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-access-grants.html).
**Topics**
+ [S3-Access-Grants-Instance und -Standort erstellen](#emr-idc-s3ag-instance)
+ [Grants für Identity-Center-Identitäten erstellen](#emr-idc-s3ag-identities)
## S3-Access-Grants-Instance und -Standort erstellen
Wenn Sie noch keine haben, erstellen Sie eine S3-Access-Grants-Instance in der AWS-Region , in der Sie Ihren EMR-Cluster starten möchten.
Verwenden Sie den folgenden AWS CLI Befehl, um eine neue Instanz mit dem Namen `MyInstance` zu erstellen:
```
aws s3control-access-grants create-access-grants-instance \
--account-id 12345678912 \
--identity-center-arn "identity-center-instance-arn" \
```
Erstellen Sie dann einen S3-Access-Grants-Standort und ersetzen Sie die roten Werte durch Ihre eigenen:
```
aws s3control-access-grants create-access-grants-location \
--account-id 12345678912 \
--location-scope s3:// \
--iam-role-arn "access-grant-role-arn" \
--region aa-example-1
```
**Anmerkung**
Definieren Sie den `iam-role-arn`-Parameter als den `accessGrantRole`-ARN.
## Grants für Identity-Center-Identitäten erstellen
Erstellen Sie abschließend die Grants für die Identitäten, die Zugriff auf Ihren Cluster haben:
```
aws s3control-access-grants create-access-grant \
--account-id 12345678912 \
--access-grants-location-id "default" \
--access-grants-location-configuration S3SubPrefix="s3-bucket-prefix"
--permission READ \
--grantee GranteeType=DIRECTORY_USER,GranteeIdentifier="your-identity-center-user-id"
```
Beispielausgabe:
```
{
"CreatedAt": "2023-09-21T23:47:24.870000+00:00",
"AccessGrantId": "1234-12345-1234-1234567",
"AccessGrantArn": "arn:aws:s3:aa-example-1-1:123456789012:access-grants/default/grant/xxxx1234-1234-5678-1234-1234567890",
"Grantee": {
"GranteeType": "DIRECTORY_USER",
"GranteeIdentifier": "5678-56789-5678-567890"
},
"AccessGrantsLocationId": "default",
"AccessGrantsLocationConfiguration": {
"S3SubPrefix": "myprefix/*"
},
"Permission": "READ",
"GrantScope": "s3://myprefix/*"
}
```
# Benutzersitzungen im Hintergrund
Mithilfe von Benutzersitzungen im Hintergrund können lang andauernde Analysen- und Machine-Learning-Workloads auch dann fortgesetzt werden, wenn sich der Benutzer von seiner Notebook-Oberfläche abgemeldet hat. Ab EMR auf EC2-Version 7.11 ist diese Funktion über die Funktion Trusted Identity Propagation von EMR-EC2 verfügbar. In den folgenden Abschnitten werden die Konfigurationsoptionen und das Verhalten von Benutzersitzungen im Hintergrund erläutert.
**Anmerkung**
Die Einstellungen für die Benutzerhintergrundsitzung wirken sich nur auf Spark-Workloads aus, die über SageMaker Unified Studio gestartet wurden. Änderungen an dieser Einstellung gelten für neue Livy-Sitzungen — bestehende aktive Sitzungen bleiben davon unberührt.
## Konfigurieren Sie Benutzer-Sitzungen im Hintergrund
Benutzerhintergrundsitzungen müssen auf zwei Ebenen aktiviert werden, damit sie ordnungsgemäß funktionieren:
1. **IAM Identity Center-Instanzebene** (von IdC-Administratoren konfiguriert)
1. **EMR-Clusterebene** (von EMR-Clusteradministratoren konfiguriert)
### Benutzer-Sitzungen im Hintergrund für Amazon EMR aktivieren
Um Benutzerhintergrundsitzungen für Sie zu aktivieren, müssen Sie den `userBackgroundSessionsEnabled` Parameter `true` in der `identityCenterConfiguration` EMR-Sicherheitskonfiguration auf setzen.
**Voraussetzungen:**
+ Für die IAM-Rolle, die zum Erstellen oder Aktualisieren der EMR-Sicherheitskonfiguration verwendet wird, ist die `sso:PutApplicationSessionConfiguration` entsprechende Genehmigung erforderlich. Diese Berechtigung ermöglicht Benutzer-Hintergrundsitzungen für die von Amazon EMR verwaltete IAM Identity Center-Anwendung.
+ Erstellen Sie eine IAM-Rolle für IAM Identity Center
+ Um Amazon EMR mit IAM Identity Center zu integrieren, erstellen Sie eine IAM-Rolle, die sich über den EMR-Cluster bei IAM Identity Center authentifiziert. Amazon EMR verwendet SigV4-Anmeldeinformationen, um die IAM Identity Center-Identität an nachgelagerte Dienste weiterzuleiten, wie z. AWS Lake Formation Ihre Rolle sollte auch über die erforderlichen Berechtigungen zum Aufrufen der nachgelagerten Dienste verfügen.
+ [Konfigurieren Sie Lake Formation für einen IAM Identity Center-fähigen EMR-Cluster](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-idc-lf.html). Die erforderlichen Rollenberechtigungen finden Sie unter: [Eine IAM-Rolle für Identity Center erstellen](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-idc-start.html#emr-idc-start-role).
+ Starten Sie Ihren EMR-Cluster mit Version 7.11 oder höher und aktivieren Sie Trusted-Identity Propagation.
**Schritt 1 — Erstellen Sie eine Identity UserBackgroundSession Center-fähige EMR-Sicherheitskonfiguration**
Benutzer müssen das `EnableUserBackgroundSession` **Flag auf** setzen`true`, damit der EMR-Dienst auf EMR-verwalteter UserBackgourndSession IDC-Anwendungsebene aktiviert werden kann. Wenn dieses Flag auf `false` oder nicht gesetzt ist, deaktiviert EMR IDC UserBackgroundSession standardmäßig.
**Beispiel für die Verwendung von: AWS CLI**
```
aws emr create-security-configuration --name "idc-userBackgroundSession-enabled-secConfig" \
--region AWS_REGION \
--security-configuration ' \
{
"AuthenticationConfiguration":{
"IdentityCenterConfiguration":{
"EnableIdentityCenter":true,
"IdentityCenterInstanceARN": "arn:aws:sso:::instance/ssoins-123xxxxxxxxxx789",
"IdentityCenterApplicationAssigmentRequired": false,
"EnableUserBackgroundSession": true,
"IAMRoleForEMRIdentityCenterApplicationARN": "arn:aws:iam::12345678912:role/YOUR_ROLE"
}
},\
"AuthorizationConfiguration": {
"IAMConfiguration": {
"EnableApplicationScopedIAMRole": true,
"ApplicationScopedIAMRoleConfiguration": {
"PropagateSourceIdentity": true
}
},\
"LakeFormationConfiguration": {
"AuthorizedSessionTagValue": "Amazon EMR"
}
},\
"EncryptionConfiguration": {
"EnableInTransitEncryption": true,
"EnableAtRestEncryption": false,
"InTransitEncryptionConfiguration": {
"TLSCertificateConfiguration": {
"CertificateProviderType": "PEM",
"S3Object": "s3://amzn-s3-demo-bucket/cert/my-certs.zip"
}
}
}
}'
```
**Schritt 2 — Einen Identity Center-fähigen Cluster erstellen und starten**
Nachdem Sie nun die IAM-Rolle eingerichtet haben, die sich bei Identity Center authentifiziert, und eine Amazon-EMR-Sicherheitskonfiguration erstellt haben, für die Identity Center aktiviert ist, können Sie Ihren identitätsbewussten Cluster erstellen und starten. Schritte zum Starten Ihres Clusters mit der erforderlichen Sicherheitskonfiguration finden Sie unter Angeben einer Sicherheitskonfiguration für einen Amazon EMR-Cluster.
### Konfigurationsmatrix
Das Verhalten der Benutzersitzungen im Hintergrund hängt sowohl von der EMR-EC2-Einstellung als auch von den Einstellungen auf Instanzebene von IAM Identity Center ab:
**Konfigurationsmatrix für Benutzerhintergrundsitzungen**
| IAM Identity Center aktiviert userBackgroundSession | Amazon EMR aktiviert userBackgroundSessions | Behavior |
| --- | --- | --- |
| Ja | TRUE | Benutzersitzung im Hintergrund aktiviert |
| Ja | FALSE | Die Sitzung läuft ab, wenn sich der Benutzer abmeldet |
| Nein | TRUE | Die Sitzung läuft mit der Benutzerabmeldung ab |
| Nein | FALSE | Die Sitzung läuft mit der Benutzerabmeldung ab |
### Standarddauer für Benutzersitzungen im Hintergrund
Standardmäßig haben alle Benutzer-Hintergrundsitzungen in IAM Identity Center ein Zeitlimit von 7 Tagen. Administratoren können diese Dauer in der Konsole von IAM Identity Center ändern. Diese Einstellung gilt für die IAM Identity Center-Instanzebene und wirkt sich auf alle unterstützten IAM Identity Center-Anwendungen innerhalb dieser Instanz aus.
+ Die Dauer kann auf einen beliebigen Wert zwischen 15 Minuten und 90 Tagen festgelegt werden.
+ Diese Einstellung wird in der IAM Identity Center-Konsole unter **Einstellungen** → **Authentifizierung** → **Konfigurieren konfiguriert** (siehe Abschnitt „Nicht interaktive Jobs“)
### Auswirkungen der Deaktivierung von Benutzersitzungen im Hintergrund
Wenn Benutzerhintergrundsitzungen in IAM Identity Center deaktiviert sind:
Bestehende Livy-Sitzungen
+ Läuft ohne Unterbrechung weiter, wenn sie mit aktivierten Benutzerhintergrundsitzungen gestartet wurden. Diese Sitzungen verwenden weiterhin ihre vorhandenen Sitzungs-Tokens im Hintergrund, bis sie auf natürliche Weise beendet werden oder explizit beendet werden.
Neue Livy-Sitzungen
+ Verwendet den standardmäßigen Übertragungsablauf für vertrauenswürdige Identitäten und wird beendet, wenn sich der Benutzer abmeldet oder seine interaktive Sitzung abläuft (z. B. beim Schließen eines Amazon SageMaker Unified JupyterLab Studio-Notebooks).
### Änderung der Dauer von Benutzersitzungen im Hintergrund
Wenn die Einstellung für die Dauer von Benutzerhintergrundsitzungen in IAM Identity Center geändert wird:
Bestehende Livy-Sitzungen
+ Läuft mit derselben Dauer der Hintergrundsitzung weiter, mit der sie gestartet wurden.
Neue Livy-Sitzungen
+ Wird die neue Sitzungsdauer für Hintergrundsitzungen verwenden.
### Überlegungen
#### Verfügbarkeit von Funktionen
Benutzer-Hintergrundsitzungen für Amazon EMR sind verfügbar für:
+ Nur Spark-Engine (Hive-Engine wird nicht unterstützt)
+ Nur interaktive Livy-Sitzungen (Batch-Jobs und Streaming-Jobs werden nicht unterstützt)
+ Amazon EMR-Release-Labels 7.11 und höher. Mit EMR Version 7.11 müssen Sie ein Bootstrap-Aktionsskript installieren, um Benutzerhintergrundsitzungen beim Erstellen eines Clusters zu aktivieren. Bitte kontaktieren Sie den AWS Support für weitere Informationen.
**Anmerkung**
Wenn Sie den von SageMaker Unified Studio bereitgestellten Cluster verwenden, benötigen Sie das Bootstrap-Aktionsskript nicht, um diese Funktion zu verwenden.
#### Auswirkungen auf die Kosten
+ Jobs werden auch dann bis zum Abschluss ausgeführt, wenn Benutzer ihre Amazon SageMaker Unified JupyterLab Studio-Sitzung beenden, und es fallen Gebühren für die gesamte Dauer des abgeschlossenen Laufs an.
+ Überwachen Sie Ihre aktiven Hintergrundsitzungen, um unnötige Kosten durch vergessene oder abgebrochene Sitzungen zu vermeiden.
#### Bedingungen für die Kündigung der Livy-Sitzung
Wenn Sie Benutzersitzungen im Hintergrund verwenden, läuft eine Livy-Sitzung so lange weiter, bis einer der folgenden Fälle eintritt:
+ Die Benutzerhintergrundsitzung läuft ab (je nach IdC-Konfiguration, bis zu 90 Tage).
+ Die Benutzerhintergrundsitzung wird manuell von einem Administrator gesperrt.
+ Die Livy-Sitzung erreicht ihr Leerlauf-Timeout (Standard: 8 Stunden nach der letzten ausgeführten Anweisung).
+ Der Benutzer stoppt oder startet den Notebook-Kernel explizit neu.
# Ü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 Trusted Identity Propagation über Identity Center mithilfe der Funktion EMR Runtime Roles auf Amazon EMR 7.8.0 und höher und nur mit Apache Spark unterstützt.
+ Um EMR-Cluster mit vertrauenswürdiger Identitätsverbreitung zu aktivieren, müssen Sie die verwenden, AWS CLI um eine Sicherheitskonfiguration zu erstellen, für die vertrauenswürdige Identitätsverbreitung aktiviert ist, und diese Sicherheitskonfiguration verwenden, wenn Sie Ihren Cluster starten. Weitere Informationen finden Sie unter [Eine Identity-Center-fähige Sicherheitskonfiguration erstellen](emr-idc-start.md#emr-idc-start-securityconfig).
+ Detaillierte Zugriffskontrollen AWS Lake Formation , die Trusted Identity Propagation verwenden, sind für Amazon EMR-Cluster auf 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 AWS Lake Formation basiert.
+ Bei Amazon EMR-Clustern, die Trusted Identity Propagation verwenden, gehören SELECT, ALTER TABLE, INSERT INTO und DROP TABLE zu den Vorgängen, die die Zugriffskontrolle auf der Grundlage von Lake Formation mit Apache Spark unterstützen.
+ Präzise Zugriffskontrollen AWS Lake Formation , die Trusted Identity Propagation verwenden, müssen die Lake Formation Identity Center-Konfiguration aktualisieren, indem die EMR-verwaltete IAM-Identity-Anwendung arn als autorisiertes Ziel hinzugefügt wird. Sie finden den ARN der von Amazon EMR verwalteten IAM Identity-Anwendung, indem Sie die `describe-security-configure` EMR-API aufrufen und nach dem Feld suchen. `IdCApplicationARN` Weitere Details: [Aktualisierung der IAM Identity Center-Integration](https://docs.aws.amazon.com/lake-formation/latest/dg/update-lf-identity-center-connection.html) zur Einrichtung von Lake Formation mit der IAM Identity Center-Konfiguration.
+ Um detaillierte Zugriffskontrollen zu verwenden AWS Lake Formation , die Trusted Identity Propagation verwenden, sollten IAM Identity-Benutzern Lake Formation Formation-Berechtigungen für die Standarddatenbank gewährt werden. Weitere Details: [Lake Formation für einen IAM Identity Center-fähigen EMR-Cluster konfigurieren](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-idc-lf.html).
+ Trusted Identity Propagation mit Amazon EMR wird in den folgenden AWS-Regionen Bereichen unterstützt:
+ `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)
# Integrieren Sie Amazon EMR mit AWS Lake Formation
AWS Lake Formation ist ein verwalteter Service, der Sie dabei unterstützt, Daten in einem Amazon Simple Storage Service (S3) Data Lake zu entdecken, zu katalogisieren, zu bereinigen und zu sichern. Lake Formation bietet detaillierten Zugriff auf Spalten-, Zeilen- oder Zellenebene auf Datenbanken und Tabellen im AWS Glue-Datenkatalog. Weitere Informationen finden Sie unter [Was ist AWS Lake Formation?](https://docs.aws.amazon.com/lake-formation/latest/dg/what-is-lake-formation.html)
Mit Amazon-EMR-Version 6.7.0 und höher können Sie die auf Lake Formation basierende Zugriffskontrolle auf Spark-, Hive- und Presto-Jobs anwenden, die Sie an Amazon-EMR-Cluster senden. Für die Integration mit Lake Formation müssen Sie einen EMR-Cluster mit einer *Laufzeit-Rolle* erstellen. Eine Laufzeit-Rolle ist eine AWS Identity and Access Management (IAM)-Rolle, der Sie Amazon-EMR-Aufträge oder Abfragen zuordnen. Amazon EMR verwendet diese Rolle dann für den Zugriff auf AWS Ressourcen. Weitere Informationen finden Sie unter [Schritte für Laufzeit-Rollen für Amazon EMR](emr-steps-runtime-roles.md).
## Wie Amazon EMR mit Lake Formation funktioniert
Nachdem Sie Amazon EMR mit Lake Formation integriert haben, können Sie Abfragen an Amazon EMR-Cluster mit der [`Step`API](https://docs.aws.amazon.com/emr/latest/APIReference/API_Step.html) oder mit SageMaker AI Studio ausführen. Anschließend bietet Lake Formation über temporäre Anmeldeinformationen für Amazon EMR Zugriff auf Daten. Dieser Prozess wird als Anmeldeinformationsvergabe bezeichnet. Weitere Informationen finden Sie unter [Was ist AWS Lake Formation?](https://docs.aws.amazon.com/lake-formation/latest/dg/what-is-lake-formation.html)
Nachfolgend finden Sie einen allgemeinen Überblick darüber, wie Amazon EMR Zugriff auf Daten erhält, die durch Sicherheitsrichtlinien von Lake Formation geschützt sind.
![\[So greift Amazon EMR auf Daten zu, die durch Sicherheitsrichtlinien von Lake Formation geschützt sind\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/images/lf-emr-security.png)
1. Ein Benutzer sendet eine Amazon-EMR-Abfrage für Daten in Lake Formation.
1. Amazon EMR fordert temporäre Anmeldeinformationen von Lake Formation an, um den Benutzerdaten Zugriff zu gewähren.
1. Lake Formation gibt temporäre Anmeldeinformationen zurück.
1. Amazon EMR sendet die Abfrageanfrage zum Abrufen von Daten aus Amazon S3.
1. Amazon EMR empfängt die Daten von Amazon S3, filtert sie und gibt Ergebnisse zurück, die auf den Benutzerberechtigungen basieren, die der Benutzer in Lake Formation definiert hat.
Weitere Informationen zum Hinzufügen von Benutzern und Gruppen zu Lake Formation-Richtlinien finden Sie unter [Erteilen von Datenkatalogberechtigungen](https://docs.aws.amazon.com/lake-formation/latest/dg/granting-catalog-permissions.html).
## Voraussetzungen
Sie müssen die folgenden Anforderungen erfüllen, bevor Sie Amazon EMR und Lake Formation integrieren können:
+ Aktivieren Sie die Laufzeit-Rollenautorisierung in Ihrem Amazon-EMR-Cluster.
+ Verwenden Sie den AWS Glue-Datenkatalog als Ihren Metadatenspeicher.
+ Definieren und verwalten Sie in Lake Formation Berechtigungen für den Zugriff auf Datenbanken, Tabellen und Spalten im AWS Glue Data Catalog. Weitere Informationen finden Sie unter [Was ist AWS Lake Formation?](https://docs.aws.amazon.com/lake-formation/latest/dg/what-is-lake-formation.html)
# Feinkörniger Zugang mit Lake Formation
Die Amazon EMR-Versionen 6.15.0 und höher bieten Unterstützung für eine differenzierte Zugriffskontrolle auf Zeilen-, Spalten- oder Zellenebene basierend auf Lake Formation. AWS In den Themen in diesem Abschnitt wird beschrieben, wie Sie über EMR Spark-Jobs oder interaktive Sitzungen mit detaillierter Zugriffskontrolle auf Lake Formation Formation-geschützte Glue Data-Katalogtabellen zugreifen können.
# Wie Amazon EMR mit Lake Formation funktioniert
Wenn Sie mit Amazon EMR 6.15.0 und höher Spark-Jobs auf Amazon EMR auf EC2-Clustern ausführen, die auf Daten im AWS Glue-Datenkatalog zugreifen, können Sie damit Berechtigungen auf Tabellen-, Zeilen-, Spalten- und Zellenebene auf Hudi-, Iceberg- oder Delta Lake-basierte Tabellen anwenden. AWS Lake Formation
In diesem Abschnitt erfahren Sie, wie Sie eine Sicherheitskonfiguration erstellen und Lake Formation so einrichten, dass es mit Amazon EMR funktioniert. Wir gehen auch darauf ein, wie Sie einen Cluster mit der Sicherheitskonfiguration starten, die Sie für Lake Formation erstellt haben.
## Schritt 1: Eine Laufzeit-Rolle für Ihren EMR-Cluster einrichten
Um die Laufzeit-Rolle für Ihren Cluster einzurichten, erstellen Sie eine Sicherheitskonfiguration. Mit einer Sicherheitskonfiguration können Sie konsistente Sicherheits-, Autorisierungs- und Authentifizierungsoptionen für alle Ihre Cluster anwenden.
1. Erstellen Sie eine Datei mit dem Namen `lf-runtime-roles-sec-cfg.json` und den folgenden Inhalten.
```
{
"AuthorizationConfiguration": {
"IAMConfiguration": {
"EnableApplicationScopedIAMRole": true,
"ApplicationScopedIAMRoleConfiguration": {
"PropagateSourceIdentity": true
}
},
"LakeFormationConfiguration": {
"AuthorizedSessionTagValue": "Amazon EMR"
}
},
"EncryptionConfiguration": {
"EnableAtRestEncryption": false,
"EnableInTransitEncryption": true,
"InTransitEncryptionConfiguration": {
"TLSCertificateConfiguration": {}
}
}
}
```
Das folgende Beispiel zeigt, wie eine Zip-Datei mit Zertifikaten in Amazon S3 für die Zertifikatskonfiguration verwendet wird:
+ Eine Zip-Datei mit Zertifikaten in Amazon S3 wird als Schlüsselanbieter verwendet. (Informationen zu [Bereitstellen von Zertifikaten für die Verschlüsselung von Daten während der Übertragung mit der Amazon-EMR-Verschlüsselung](emr-encryption-enable.md#emr-encryption-certificates) den Zertifikatsanforderungen finden Sie unter.)
```
"TLSCertificateConfiguration": {
"CertificateProviderType": "PEM",
"S3Object": "s3://MyConfigStore/artifacts/MyCerts.zip"
}
```
Das folgende Beispiel zeigt, wie ein benutzerdefinierter Schlüsselanbieter für die Zertifikatskonfiguration verwendet wird:
+ Ein benutzerdefinierter Schlüsselanbieter wird verwendet. (Informationen zu [Bereitstellen von Zertifikaten für die Verschlüsselung von Daten während der Übertragung mit der Amazon-EMR-Verschlüsselung](emr-encryption-enable.md#emr-encryption-certificates) den Zertifikatsanforderungen finden Sie unter.)
```
"TLSCertificateConfiguration": {
"CertificateProviderType": "Custom",
"S3Object": "s3://MyConfig/artifacts/MyCerts.jar",
"CertificateProviderClass": "com.mycompany.MyCertProvider"
}
```
1. Um als Nächstes sicherzustellen, dass das Sitzungs-Tag Lake Formation autorisieren kann, setzen Sie die `LakeFormationConfiguration/AuthorizedSessionTagValue`-Eigenschaft auf `Amazon EMR`.
1. Verwenden Sie den folgenden Befehl, um die Amazon-EMR-Sicherheitskonfiguration zu erstellen.
```
aws emr create-security-configuration \
--name 'iamconfig-with-iam-lf' \
--security-configuration file://lf-runtime-roles-sec-cfg.json
```
Alternativ können Sie die [Amazon-EMR-Konsole](https://console.aws.amazon.com//emr) verwenden, um eine Sicherheitskonfiguration mit benutzerdefinierten Einstellungen zu erstellen.
## Schritt 2: Starten eines Amazon-EMR-Clusters
Jetzt sind Sie bereit, einen EMR-Cluster mit der Sicherheitskonfiguration zu starten, die Sie im vorherigen Schritt erstellt haben. Weitere Informationen zum Erstellen einer Sicherheitskonfiguration finden Sie unter [Verwenden Sie Sicherheitskonfigurationen, um die Amazon EMR-Cluster-Sicherheit einzurichten](emr-security-configurations.md) und [Schritte für Laufzeit-Rollen für Amazon EMR](emr-steps-runtime-roles.md).
## Schritt 3: Auf Lake Formation basierende Berechtigungen auf Spalten-, Zeilen- oder Zellenebene mit Amazon EMR-Runtime-Rollen einrichten
Um mit Lake Formation eine differenzierte Zugriffskontrolle auf Spalten-, Zeilen- oder Zellenebene anzuwenden, muss der Data Lake-Administrator für Lake Formation den Wert für die Sitzungs-Tag-Konfiguration festlegen`Amazon EMR`. `AuthorizedSessionTagValue` Lake Formation verwendet dieses Sitzungs-Tag, um Anrufer zu autorisieren und Zugriff auf den Data Lake zu gewähren. Sie können dieses Sitzungs-Tag im Abschnitt **Anwendungsintegrationseinstellungen** der Lake Formation Formation-Konsole festlegen. *123456789012*Ersetzen Sie es durch Ihre eigene AWS-Konto ID.
## Schritt 4: AWS Glue- und Lake Formation Formation-Grants für Amazon EMR-Runtime-Rollen konfigurieren
Um mit der Einrichtung der auf Lake Formation basierenden Zugriffskontrolle mit Amazon EMR-Runtime-Rollen fortzufahren, müssen Sie AWS Glue- und Lake Formation Formation-Grants für Amazon EMR-Runtime-Rollen konfigurieren. Damit Ihre IAM-Laufzeitrollen mit Lake Formation interagieren können, gewähren Sie ihnen Zugriff mit `lakeformation:GetDataAccess` und `glue:Get*`.
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-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 verfügen. Weitere Informationen zur Zugriffskontrolle für Lake Formation finden Sie unter [Übersicht über die Zugriffskontrolle für Lake Formation](https://docs.aws.amazon.com/lake-formation/latest/dg/lf-permissions-overview.html).
1. Erstellen Sie die Datei `emr-runtime-roles-lake-formation-policy.json` mit folgendem Inhalt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "LakeFormationManagedAccess",
"Effect": "Allow",
"Action": [
"lakeformation:GetDataAccess",
"glue:Get*",
"glue:Create*",
"glue:Update*"
],
"Resource": [
"*"
]
}
]
}
```
------
1. Erstellen Sie die zugehörige IAM-Richtlinie.
```
aws iam create-policy \
--policy-name emr-runtime-roles-lake-formation-policy \
--policy-document file://emr-runtime-roles-lake-formation-policy.json
```
1. Um diese Richtlinie Ihren IAM-Laufzeit-Rollen zuzuweisen, folgen Sie den Schritten unter [Verwalten von AWS Lake Formation -Berechtigungen](https://docs.aws.amazon.com/lake-formation/latest/dg/managing-permissions.html).
Sie können jetzt Laufzeit-Rollen und Lake Formation verwenden, um Berechtigungen auf Tabellen- und Spaltenebene anzuwenden. Sie können auch eine Quellidentität verwenden, um Aktionen zu steuern und Vorgänge zu AWS CloudTrailüberwachen.
Legen Sie für jede IAM-Rolle, die Sie als Laufzeit-Rolle verwenden möchten, die folgende Vertrauensrichtlinie fest und ersetzen Sie sie `EMR_EC2_DefaultRole` durch Ihre Instance-Profilrolle. Informationen zum Ändern der Vertrauensrichtlinie einer IAM-Rolle finden Sie unter [Vertrauensrichtlinie für Rollen ändern](https://docs.aws.amazon.com//IAM/latest/UserGuide/roles-managingrole-editing-console.html).
```
{
"Sid":"AllowAssumeRole",
"Effect":"Allow",
"Principal":{
"AWS":"arn:aws:iam:::role/EMR_EC2_DefaultRole"
},
"Action":[
"sts:AssumeRole",
"sts:TagSession"
]
}
```
Ein detailliertes end-to-end Beispiel finden Sie unter [Schritte zur Einführung von Runtime-Rollen für Amazon EMR](https://aws.amazon.com/blogs/big-data/introducing-runtime-roles-for-amazon-emr-steps-use-iam-roles-and-aws-lake-formation-for-access-control-with-amazon-emr/).
Informationen zur Integration mit Iceberg und AWS Glue Data Catalog für eine Hierarchie mit mehreren Katalogen finden [Sie unter Konfigurieren von Spark für den Zugriff auf eine Hierarchie mit mehreren Katalogen in AWS Glue Data Catalog](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-multi-catalog.html#emr-lakehouse-using-spark-access).
# Unterstützung für das offene Tabellenformat
Die Amazon EMR-Versionen 6.15.0 und höher bieten Unterstützung für eine differenzierte Zugriffskontrolle, die auf Hive-Tabellen, Apache Iceberg, Apache Hudi und Delta Lake basiert, wenn Sie Daten AWS Lake Formation mit Spark SQL lesen und schreiben. Amazon EMR unterstützt die Zugriffskontrolle auf Tabellen-, Zeilen-, Spalten- und Zellenebene mit Apache Hudi. Die Amazon EMR-Versionen 6.15.0 und höher bieten Unterstützung für eine differenzierte Zugriffskontrolle auf Zeilen-, Spalten- oder Zellenebene basierend auf Lake Formation. AWS Ab EMR 7.12 werden DML- und DDL-Operationen, die Tabellendaten ändern, für Apache Hive-, Apache Iceberg- und Delta Lake-Tabellen mit von Lake Formation vergebenen Anmeldeinformationen unterstützt.
Die Themen in diesem Abschnitt behandeln, wie Sie über EMR Spark-Jobs oder interaktive Sitzungen mit detaillierter Zugriffskontrolle auf registrierte Lake Formation-Tabellen in offenen Tabellenformaten zugreifen können.
## Benötigte Berechtigungen
### Tabellen, die nicht registriert sind in AWS Lake Formation
Bei Tabellen AWS Lake Formation, bei denen nicht registriert ist, greift die Job-Runtime-Rolle sowohl auf den AWS Glue-Datenkatalog als auch auf die zugrunde liegenden Tabellendaten in Amazon S3 zu. Dazu muss die Job-Runtime-Rolle über die entsprechenden IAM-Berechtigungen sowohl für AWS Glue- als auch für Amazon S3 S3-Operationen verfügen.
### Tabellen sind registriert in AWS Lake Formation
Bei Tabellen AWS Lake Formation, bei denen registriert ist, greift die Job-Runtime-Rolle auf die Metadaten des AWS Glue-Datenkatalogs zu, während temporäre Anmeldeinformationen, die von Lake Formation bereitgestellt wurden, auf die zugrunde liegenden Tabellendaten in Amazon S3 zugreifen. Die Lake Formation Formation-Berechtigungen, die zur Ausführung eines Vorgangs erforderlich sind, hängen vom AWS Glue Data Catalog und den Amazon S3 S3-API-Aufrufen ab, die der Spark-Job initiiert, und lassen sich wie folgt zusammenfassen:
+ Die **DESCRIBE-Berechtigung** ermöglicht es der Runtime-Rolle, Tabellen- oder Datenbankmetadaten im Datenkatalog zu lesen
+ Die **ALTER-Berechtigung** ermöglicht der Runtime-Rolle, Tabellen- oder Datenbankmetadaten im Datenkatalog zu ändern
+ Die **DROP-Berechtigung** ermöglicht der Runtime-Rolle, Tabellen- oder Datenbankmetadaten aus dem Datenkatalog zu löschen
+ Die **SELECT-Berechtigung** ermöglicht es der Runtime-Rolle, Tabellendaten aus Amazon S3 zu lesen
+ Die **INSERT-Berechtigung** ermöglicht es der Runtime-Rolle, Tabellendaten in Amazon S3 zu schreiben
+ Die **DELETE-Berechtigung** ermöglicht es der Runtime-Rolle, Tabellendaten aus Amazon S3 zu löschen
**Anmerkung**
Lake Formation wertet Berechtigungen träge aus, wenn ein Spark-Job AWS Glue zum Abrufen von Tabellenmetadaten und Amazon S3 zum Abrufen von Tabellendaten aufruft. Jobs, die eine Runtime-Rolle mit unzureichenden Berechtigungen verwenden, schlagen erst fehl, wenn Spark einen AWS Glue- oder Amazon S3-Aufruf tätigt, für den die fehlende Berechtigung erforderlich ist.
**Anmerkung**
In der folgenden unterstützten Tabellenmatrix:
Als **Unterstützt** markierte Operationen verwenden ausschließlich Lake Formation-Anmeldeinformationen, um auf Tabellendaten für Tabellen zuzugreifen, die bei Lake Formation registriert sind. Wenn die Lake Formation Formation-Berechtigungen nicht ausreichen, greift der Vorgang nicht auf Anmeldeinformationen für Runtime-Rollen zurück. Bei Tabellen, die nicht bei Lake Formation registriert sind, greifen die Anmeldeinformationen der Job-Runtime-Rolle auf die Tabellendaten zu.
Operationen, die als **Unterstützt mit IAM-Berechtigungen am Amazon S3-Standort** markiert sind, verwenden keine Lake Formation Formation-Anmeldeinformationen für den Zugriff auf die zugrunde liegenden Tabellendaten in Amazon S3. Um diese Operationen auszuführen, muss die Job-Runtime-Rolle über die erforderlichen Amazon S3 S3-IAM-Berechtigungen für den Zugriff auf die Tabellendaten verfügen, unabhängig davon, ob die Tabelle bei Lake Formation registriert ist.
------
#### [ Hive ]
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/emr-lf-fgac1.html)
------
#### [ Iceberg ]
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/emr-lf-fgac1.html)
**Spark-Konfiguration für Iceberg:** Wenn Sie das Iceberg-Format verwenden möchten, legen Sie die folgenden Konfigurationen fest. `DB_LOCATION`Ersetzen Sie durch den Amazon S3 S3-Pfad, in dem sich Ihre Iceberg-Tabellen befinden, und ersetzen Sie die Platzhalter für Region und Konto-ID durch Ihre eigenen Werte.
```
spark-sql \
--conf spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions
--conf spark.sql.catalog.spark_catalog=org.apache.iceberg.spark.SparkSessionCatalog
--conf spark.sql.catalog.spark_catalog.warehouse=s3://DB_LOCATION
--conf spark.sql.catalog.spark_catalog.catalog-impl=org.apache.iceberg.aws.glue.GlueCatalog
--conf spark.sql.catalog.spark_catalog.io-impl=org.apache.iceberg.aws.s3.S3FileIO
--conf spark.sql.catalog.spark_catalog.glue.account-id=ACCOUNT_ID
--conf spark.sql.catalog.spark_catalog.glue.id=ACCOUNT_ID
--conf spark.sql.catalog.spark_catalog.client.region=AWS_REGION
```
Wenn Sie das Iceberg-Format in früheren EMR-Versionen verwenden möchten, verwenden Sie stattdessen den folgenden Befehl:
```
spark-sql \
--conf spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions,com.amazonaws.emr.recordserver.connector.spark.sql.RecordServerSQLExtension
--conf spark.sql.catalog.spark_catalog=org.apache.iceberg.spark.SparkCatalog
--conf spark.sql.catalog.spark_catalog.warehouse=s3://DB_LOCATION
--conf spark.sql.catalog.spark_catalog.catalog-impl=org.apache.iceberg.aws.glue.GlueCatalog
--conf spark.sql.catalog.spark_catalog.io-impl=org.apache.iceberg.aws.s3.S3FileIO
--conf spark.sql.catalog.spark_catalog.glue.account-id=ACCOUNT_ID
--conf spark.sql.catalog.spark_catalog.glue.id=ACCOUNT_ID
--conf spark.sql.catalog.spark_catalog.client.assume-role.region=AWS_REGION
--conf spark.sql.catalog.spark_catalog.lf.managed=true
```
**Beispiele:**
Hier sind einige Beispiele für die Arbeit mit Iceberg-Tabellen:
```
-- Create an Iceberg table
CREATE TABLE my_iceberg_table (
id BIGINT,
name STRING,
created_at TIMESTAMP
) USING ICEBERG;
-- Insert data
INSERT INTO my_iceberg_table VALUES (1, 'Alice', current_timestamp());
-- Query the table
SELECT * FROM my_iceberg_table;
```
------
#### [ Hudi ]
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/emr-lf-fgac1.html)
**Spark-Konfiguration für Hudi:**
Verwenden Sie den folgenden Befehl, um die Spark-Shell auf EMR 7.10 oder höheren Versionen zu starten:
```
spark-sql
--jars /usr/lib/hudi/hudi-spark-bundle.jar \
--conf spark.sql.catalog.spark_catalog=org.apache.spark.sql.hudi.catalog.HoodieCatalog \
--conf spark.sql.extensions=org.apache.spark.sql.hudi.HoodieSparkSessionExtension
```
Um die Spark-Shell auf früheren EMR-Versionen zu starten, verwenden Sie stattdessen den folgenden Befehl:
```
spark-sql
--jars /usr/lib/hudi/hudi-spark-bundle.jar \
--conf spark.serializer=org.apache.spark.serializer.KryoSerializer \
--conf spark.sql.catalog.spark_catalog=org.apache.spark.sql.hudi.catalog.HoodieCatalog \
--conf spark.sql.extensions=org.apache.spark.sql.hudi.HoodieSparkSessionExtension,com.amazonaws.emr.recordserver.connector.spark.sql.RecordServerSQLExtension \
--conf spark.sql.catalog.spark_catalog.lf.managed=true
```
**Beispiele:**
Hier sind einige Beispiele für die Arbeit mit Hudi-Tabellen:
```
-- Create a Hudi table
CREATE TABLE my_hudi_table (
id BIGINT,
name STRING,
created_at TIMESTAMP
) USING HUDI
TBLPROPERTIES (
'type' = 'cow',
'primaryKey' = 'id'
);
-- Insert data
INSERT INTO my_hudi_table VALUES (1, 'Alice', current_timestamp());
-- Query the latest snapshot
SELECT * FROM my_hudi_table;
```
Um den neuesten Snapshot von copy-on-write Tabellen abzufragen:
```
SELECT * FROM my_hudi_cow_table
```
```
spark.read.table("my_hudi_cow_table")
```
Um die neuesten komprimierten Daten von `MOR`-Tabellen abzufragen, können Sie die leseoptimierte Tabelle mit dem Suffix `_ro` abfragen:
```
SELECT * FROM my_hudi_mor_table_ro
```
```
spark.read.table("my_hudi_mor_table_ro")
```
------
#### [ Delta Lake ]
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/emr-lf-fgac1.html)
**Spark-Konfiguration für Delta Lake:**
Führen Sie den folgenden Befehl aus, um Delta Lake mit Lake Formation auf EMR 7.10 und höher zu verwenden:
```
spark-sql \
--conf spark.sql.extensions=io.delta.sql.DeltaSparkSessionExtension \
--conf spark.sql.catalog.spark_catalog=org.apache.spark.sql.delta.catalog.DeltaCatalog
```
Um Delta Lake mit Lake Formation auf EMR 6.15 bis 7.9 zu verwenden, führen Sie den folgenden Befehl aus
```
spark-sql \
--conf spark.sql.extensions=io.delta.sql.DeltaSparkSessionExtension,com.amazonaws.emr.recordserver.connector.spark.sql.RecordServerSQLExtension \
--conf spark.sql.catalog.spark_catalog=org.apache.spark.sql.delta.catalog.DeltaCatalog \
--conf spark.sql.catalog.spark_catalog.lf.managed=true
```
Wenn Sie möchten, dass Lake Formation einen Datensatzserver zur Verwaltung Ihres Spark-Katalogs verwendet, legen Sie `spark.sql.catalog..lf.managed` den Wert auf true fest.
**Beispiele:**
Hier sind einige Beispiele für die Arbeit mit Delta Lake-Tabellen:
```
-- Create a Delta Lake table
CREATE TABLE my_delta_table (
id BIGINT,
name STRING,
created_at TIMESTAMP
) USING DELTA;
-- Insert data
INSERT INTO my_delta_table VALUES (1, 'Alice', current_timestamp());
-- Query the table
SELECT * FROM my_delta_table;
-- Update data
UPDATE my_delta_table SET name = 'Alice Smith' WHERE id = 1;
-- Merge data
MERGE INTO my_delta_table AS target
USING (SELECT 2 as id, 'Bob' as name, current_timestamp() as created_at) AS source
ON target.id = source.id
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *;
```
**Erstellen einer Delta Lake-Tabelle im AWS Glue Data Catalog**
Amazon EMR with Lake Formation unterstützt keine DDL-Befehle und die Erstellung von Delta-Tabellen in EMR-Versionen vor 7.12. Gehen Sie wie folgt vor, um Tabellen im AWS Glue-Datenkatalog zu erstellen.
1. Verwenden Sie das folgende Beispiel, um eine Delta-Tabelle zu erstellen. Stellen Sie sicher, dass Ihr S3-Standort existiert.
```
spark-sql \
--conf "spark.sql.extensions=io.delta.sql.DeltaSparkSessionExtension" \
--conf "spark.sql.catalog.spark_catalog=org.apache.spark.sql.delta.catalog.DeltaCatalog"
> CREATE DATABASE if not exists LOCATION 's3:///transactionaldata/native-delta//';
> CREATE TABLE (x INT, y STRING, z STRING) USING delta;
> INSERT INTO VALUES (1, 'a1', 'b1');
```
1. Um die Details Ihrer Tabelle zu sehen, gehen Sie zu [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/).
1. Erweitern Sie in der linken Navigationsleiste den **Datenkatalog**, wählen Sie **Tabellen** und dann die Tabelle aus, die Sie erstellt haben. Unter **Schema** sollten Sie sehen, dass die Delta-Tabelle, die Sie mit Spark erstellt haben, alle Spalten in einem Datentyp von `array` in AWS Glue speichert.
1. Um Filter auf Spalten- und Zellenebene in Lake Formation zu definieren, entfernen Sie die `col` Spalte aus Ihrem Schema und fügen Sie dann die Spalten hinzu, die sich in Ihrem Tabellenschema befinden. Fügen Sie in diesem Beispiel die Spalten `x``y`, und hinzu. `z`
------
Mit dieser Funktion können Sie Snapshot-Abfragen für copy-on-write Tabellen ausführen, um den neuesten Snapshot der Tabelle zu einem bestimmten Commit- oder Komprimierungszeitpunkt abzufragen. Derzeit muss ein Lake Formation-fähiger Amazon EMR-Cluster die Commit-Zeitspalte von Hudi abrufen, um inkrementelle Abfragen und Zeitreiseabfragen durchzuführen. Die Syntax und die Funktion von Spark werden nicht unterstützt. `timestamp as of` `Spark.read()` Die richtige Syntax ist`select * from table where _hoodie_commit_time <= point_in_time`. Weitere Informationen finden Sie unter [Point-in-Time-Time-Travel-Abfragen in der Hudi-Tabelle](https://cwiki.apache.org/confluence/display/HUDI/RFC+-+07+%3A+Point+in+time+Time-Travel+queries+on+Hudi+table).
**Anmerkung**
Die Leistung von Lesevorgängen auf Lake Formation-Clustern kann aufgrund von Optimierungen, die nicht unterstützt werden, langsamer sein. Zu diesen Features gehören das Auflisten von Dateien auf der Grundlage von Hudi-Metadaten und das Überspringen von Daten. Wir empfehlen Ihnen, die Leistung Ihrer Anwendung zu testen, um sicherzustellen, dass sie Ihrem SLA entspricht.
# Arbeiten mit Glue-Datenkatalogansichten in Amazon EMR
**Anmerkung**
Das Erstellen und Verwalten von AWS Glue-Datenkatalog-Ansichten zur Verwendung mit EMR auf EC2 ist mit [Amazon EMR Version 7.10.0](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-7100-release.html) und höher verfügbar.
Sie können Ansichten im AWS Glue-Datenkatalog für die Verwendung mit EMR auf EC2 erstellen und verwalten. Diese werden allgemein als AWS Glue Data Catalog-Ansichten bezeichnet. Diese Ansichten sind nützlich, da sie mehrere SQL-Abfrage-Engines unterstützen, sodass Sie über verschiedene AWS Dienste hinweg auf dieselbe Ansicht zugreifen können, z. B. EMR auf EC2 und Amazon Amazon Athena Redshift.
Indem Sie eine Ansicht im Datenkatalog erstellen, können Sie mithilfe von Ressourcenzuweisungen und tagbasierten Zugriffskontrollen Zugriff AWS Lake Formation darauf gewähren. Mit dieser Methode der Zugriffskontrolle müssen Sie keinen zusätzlichen Zugriff auf die Tabellen konfigurieren, auf die Sie beim Erstellen der Ansicht verwiesen haben. Diese Methode zum Gewähren von Berechtigungen wird als Definer-Semantik bezeichnet, und diese Ansichten werden als Definer-Ansichten bezeichnet. Weitere Informationen zur Zugriffskontrolle in Lake Formation finden Sie unter [Gewähren und Widerrufen von Berechtigungen für Datenkatalogressourcen](https://docs.aws.amazon.com/lake-formation/latest/dg/granting-catalog-permissions.html) im AWS Lake Formation Developer Guide.
Data-Catalog-Ansichten sind in folgenden Anwendungsfällen nützlich:
+ **Präzisere Zugriffskontrolle** – Sie können eine Ansicht erstellen, die den Datenzugriff auf der Grundlage der vom Benutzer benötigten Berechtigungen einschränkt. Mithilfe von Ansichten im Datenkatalog können Sie beispielsweise verhindern, dass Mitarbeiter, die nicht in der Personalabteilung arbeiten, persönlich identifizierbare Informationen (PII) sehen.
+ **Vollständige Ansichtsdefinition** — Indem Sie Filter auf Ihre Ansicht im Datenkatalog anwenden, stellen Sie sicher, dass die in einer Ansicht im Datenkatalog verfügbaren Datensätze immer vollständig sind.
+ **Verbesserte Sicherheit** — Die zur Erstellung der Ansicht verwendete Abfragedefinition muss vollständig sein. Dieser Vorteil bedeutet, dass Ansichten im Datenkatalog weniger anfällig für SQL-Befehle von böswilligen Akteuren sind.
+ **Einfaches Teilen von Daten** — Teilen Sie Daten mit anderen AWS Konten, ohne Daten verschieben zu müssen. Weitere Informationen finden Sie unter [Kontoübergreifender Datenaustausch in Lake Formation](https://docs.aws.amazon.com/lake-formation/latest/dg/cross-account-permissions.html).
## Erstellen einer Data-Catalog-Ansicht
Es gibt verschiedene Möglichkeiten, eine Datenkatalogansicht zu erstellen. Dazu gehört die Verwendung von AWS CLI oder Spark-SQL. Es folgen einige Beispiele.
------
#### [ Using SQL ]
Im Folgenden wird die Syntax für die Erstellung einer Datenkatalogansicht veranschaulicht. Notieren Sie sich den `MULTI DIALECT` Ansichtstyp. Dies unterscheidet die Datenkatalogansicht von anderen Ansichten. Das `SECURITY` Prädikat ist angegeben als. `DEFINER` Dies weist auf eine Datenkatalogansicht mit `DEFINER` Semantik hin.
```
CREATE [ OR REPLACE ] PROTECTED MULTI DIALECT VIEW [IF NOT EXISTS] view_name
[(column_name [COMMENT column_comment], ...) ]
[ COMMENT view_comment ]
[TBLPROPERTIES (property_name = property_value, ... )]
SECURITY DEFINER
AS query;
```
Im Folgenden finden Sie eine `CREATE` Beispielanweisung, die der Syntax folgt:
```
CREATE PROTECTED MULTI DIALECT VIEW catalog_view
SECURITY DEFINER
AS
SELECT order_date, sum(totalprice) AS price
FROM source_table
GROUP BY order_date
```
Sie können eine Ansicht auch im Probelaufmodus mit SQL erstellen, um die Erstellung der Ansicht zu testen, ohne die Ressource tatsächlich zu erstellen. Die Verwendung dieser Option führt zu einem „Probelauf“, der die Eingabe validiert und, falls die Validierung erfolgreich ist, die JSON des AWS Glue-Tabellenobjekts zurückgibt, das die Ansicht darstellt. In diesem Fall wird die tatsächliche Ansicht nicht erstellt.
```
CREATE [ OR REPLACE ] PROTECTED MULTI DIALECT VIEW view_name
SECURITY DEFINER
[ SHOW VIEW JSON ]
AS view-sql
```
------
#### [ Using the AWS CLI ]
**Anmerkung**
Wenn Sie den CLI-Befehl verwenden, wird das SQL, das zum Erstellen der Ansicht verwendet wurde, nicht analysiert. Dies kann dazu führen, dass die Ansicht zwar erstellt wird, Abfragen jedoch nicht erfolgreich sind. Testen Sie unbedingt Ihre SQL-Syntax, bevor Sie die Ansicht erstellen.
Sie verwenden den folgenden CLI-Befehl, um eine Ansicht zu erstellen:
```
aws glue create-table --cli-input-json '{
"DatabaseName": "database",
"TableInput": {
"Name": "view",
"StorageDescriptor": {
"Columns": [
{
"Name": "col1",
"Type": "data-type"
},
...
{
"Name": "col_n",
"Type": "data-type"
}
],
"SerdeInfo": {}
},
"ViewDefinition": {
"SubObjects": [
"arn:aws:glue:aws-region:aws-account-id:table/database/referenced-table1",
...
"arn:aws:glue:aws-region:aws-account-id:table/database/referenced-tableN",
],
"IsProtected": true,
"Representations": [
{
"Dialect": "SPARK",
"DialectVersion": "1.0",
"ViewOriginalText": "Spark-SQL",
"ViewExpandedText": "Spark-SQL"
}
]
}
}
}'
```
------
## Unterstützte Ansichtsvorgänge
Die folgenden Befehlsfragmente zeigen Ihnen verschiedene Möglichkeiten, mit Data-Catalog-Ansichten zu arbeiten:
+ **ANSICHT ERSTELLEN**
Erstellt eine Data-Catalog-Ansicht. Dies ist ein Beispiel für das Erstellen einer Ansicht aus einer vorhandenen Tabelle:
```
CREATE PROTECTED MULTI DIALECT VIEW catalog_view
SECURITY DEFINER AS SELECT * FROM my_catalog.my_database.source_table
```
+ **ALTER VIEW**
Verfügbare Syntax:
+ `ALTER VIEW view_name [FORCE] ADD DIALECT AS query`
+ `ALTER VIEW view_name [FORCE] UPDATE DIALECT AS query`
+ `ALTER VIEW view_name DROP DIALECT`
Sie können die Option `FORCE ADD DIALECT` verwenden, um das Aktualisieren des Schemas und der Unterobjekte gemäß dem neuen Engine-Dialekt zu erzwingen. Beachten Sie, dass dies zu Abfragefehlern führen kann, wenn Sie nicht auch `FORCE` verwenden, um andere Engine-Dialekte zu aktualisieren. Hier ein Beispiel:
```
ALTER VIEW catalog_view FORCE ADD DIALECT
AS
SELECT order_date, sum(totalprice) AS price
FROM source_table
GROUP BY orderdate;
```
Unten wird gezeigt, wie Sie eine Ansicht ändern, um den Dialekt zu aktualisieren:
```
ALTER VIEW catalog_view UPDATE DIALECT AS
SELECT count(*) FROM my_catalog.my_database.source_table;
```
+ **DESCRIBE VIEW**
Verfügbare Syntax für die Beschreibung einer Ansicht:
+ `SHOW COLUMNS {FROM|IN} view_name [{FROM|IN} database_name]`— Wenn der Benutzer über die erforderlichen AWS Glue- und Lake Formation Formation-Berechtigungen verfügt, um die Ansicht zu beschreiben, kann er die Spalten auflisten. Unten sehen Sie einige Beispielbefehle zum Anzeigen von Spalten:
```
SHOW COLUMNS FROM my_database.source_table;
SHOW COLUMNS IN my_database.source_table;
```
+ `DESCRIBE view_name`— Wenn der Benutzer über die erforderlichen AWS Glue- und Lake Formation Formation-Berechtigungen zur Beschreibung der Ansicht verfügt, kann er die Spalten in der Ansicht zusammen mit ihren Metadaten auflisten.
+ **DROP VIEW**
Verfügbare Syntax:
+ `DROP VIEW [ IF EXISTS ] view_name`
Das folgende Beispiel zeigt eine `DROP`-Anweisung, die testet, ob eine Ansicht vorhanden ist, bevor sie gelöscht wird:
```
DROP VIEW IF EXISTS catalog_view;
```
+ **ANSICHT ANZEIGEN, ANSICHT ERSTELLEN**
+ `SHOW CREATE VIEW view_name` – Zeigt die SQL-Anweisung an, die die angegebene Ansicht erstellt. Dies ist ein Beispiel für das Erstellen einer Data-Catalog-Ansicht:
```
SHOW CREATE TABLE my_database.catalog_view;
CREATE PROTECTED MULTI DIALECT VIEW my_catalog.my_database.catalog_view (
net_profit,
customer_id,
item_id,
sold_date)
TBLPROPERTIES (
'transient_lastDdlTime' = '1736267222')
SECURITY DEFINER AS SELECT * FROM
my_database.store_sales_partitioned_lf WHERE customer_id IN (SELECT customer_id from source_table limit 10)
```
+ **SHOW VIEWS**
Listet alle Ansichten im Katalog auf, z. B. reguläre Ansichten, Ansichten mit mehreren Dialekten (MDV) und MDV ohne Spark-Dialekt. Die verfügbare Syntax lautet wie folgt:
+ `SHOW VIEWS [{ FROM | IN } database_name] [LIKE regex_pattern]`:
Im Folgenden finden Sie einen Beispielbefehl zum Anzeigen von Ansichten:
```
SHOW VIEWS IN marketing_analytics LIKE 'catalog_view*';
```
Weitere Informationen zum Erstellen und Konfigurieren von Datenkatalog-Ansichten finden Sie unter [Building AWS Glue Data Catalog Views](https://docs.aws.amazon.com/lake-formation/latest/dg/working-with-views.html) im AWS Lake Formation Developer Guide.
## Abfrage einer Data-Catalog-Ansicht
Nachdem Sie eine Datenkatalog-Ansicht erstellt haben, können Sie sie mit einem Amazon EMR Spark-Job abfragen, für den eine detaillierte AWS Lake Formation Zugriffskontrolle aktiviert ist. Die Job-Runtime-Rolle muss über die Lake Formation `SELECT` Formation-Berechtigung in der Datenkatalogansicht verfügen. Sie müssen keinen Zugriff auf die zugrunde liegenden Tabellen gewähren, auf die in der Ansicht verwiesen wird.
Sobald Sie alles eingerichtet haben, können Sie Ihre Ansicht abfragen. Nachdem Sie beispielsweise eine Amazon EMR-Anwendung in EMR Studio erstellt haben, können Sie die folgende Abfrage ausführen, um auf eine Ansicht zuzugreifen.
```
SELECT * from my_database.catalog_view LIMIT 10;
```
Eine hilfreiche Funktion ist die. `invoker_principal` Sie gibt den eindeutigen Bezeichner der EMRS-Job-Runtime-Rolle zurück. Dies kann verwendet werden, um die View-Ausgabe auf der Grundlage des aufrufenden Prinzipals zu steuern. Sie können dies verwenden, um Ihrer Ansicht eine Bedingung hinzuzufügen, die die Abfrageergebnisse auf der Grundlage der aufrufenden Rolle verfeinert. Die Job-Runtime-Rolle muss über die Berechtigung für die `LakeFormation:GetDataLakePrincipal` IAM-Aktion verfügen, um diese Funktion verwenden zu können.
```
select invoker_principal();
```
Sie können diese Funktion beispielsweise einer `WHERE` Klausel hinzufügen, um die Abfrageergebnisse zu verfeinern.
## Überlegungen und Einschränkungen
Wenn Sie Datenkatalogsichten erstellen, gilt Folgendes:
+ Sie können Datenkatalogansichten nur mit Amazon EMR 7.10 und höher erstellen.
+ Der Data-Catalog-Ansicht-Definer muss `SELECT`-Zugriff auf die zugrunde liegenden Basistabellen haben, auf die in der Ansicht zugegriffen wird. Das Erstellen der Data-Catalog-Ansicht schlägt fehl, wenn einer bestimmten Basistabelle Lake-Formation-Filter zugewiesen wurden, die der Definier-Rolle zugewiesen wurden.
+ Basistabellen dürfen nicht über die `IAMAllowedPrincipals` Data Lake-Berechtigung in Lake Formation verfügen. Falls vorhanden, tritt der Fehler *Multi Dialect views may only reference tables without IAMAllowed Principals permissions* auf.
+ Der Amazon-S3-Speicherort der Tabelle muss als Data-Lake-Speicherort registriert sein. Wenn die Tabelle nicht registriert ist, tritt der Fehler *Multi Dialect views may only reference Lake Formation managed tables* auf. Informationen zur Registrierung von Amazon S3 S3-Standorten in Lake Formation finden Sie unter [Registrierung eines Amazon S3 S3-Standorts](https://docs.aws.amazon.com/lake-formation/latest/dg/register-location.html) im AWS Lake Formation Entwicklerhandbuch.
+ Sie können nur `PROTECTED`-Data-Catalog-Ansichten erstellen. `UNPROTECTED`-Ansichten werden nicht unterstützt.
+ Sie können in einer Datenkatalog-Ansichtsdefinition nicht auf Tabellen in einem anderen AWS Konto verweisen. Sie können auch nicht auf eine Tabelle in demselben Konto verweisen, das sich in einer separaten Region befindet.
+ Um Daten für ein Konto oder eine Region gemeinsam zu nutzen, muss die gesamte Ansicht mithilfe von Lake Formation Formation-Ressourcenlinks konto- und regionsübergreifend geteilt werden.
+ Benutzerdefinierte Funktionen (UDFs) werden nicht unterstützt.
+ Sie können Ansichten verwenden, die auf Iceberg-Tabellen basieren. Die Open-Table-Formate Apache Hudi und Delta Lake werden ebenfalls unterstützt.
+ In Data-Catalog-Ansichten kann nicht auf andere Ansichten verwiesen werden.
+ Ein AWS Ansichtschema für den Glue Data Catalog wird immer in Kleinbuchstaben gespeichert. Wenn Sie beispielsweise eine DDL-Anweisung verwenden, um eine Glue-Datenkatalog-Ansicht mit einer Spalte namens zu erstellen`Castle`, wird die im Glue-Datenkatalog erstellte Spalte in Kleinbuchstaben umgewandelt, also. `castle` Wenn Sie dann den Spaltennamen in einer DML-Abfrage als `Castle` oder angeben`CASTLE`, schreibt EMR Spark den Namen für Sie in Kleinbuchstaben, um die Abfrage auszuführen. Die Spaltenüberschrift wird jedoch in der Groß-/Kleinschreibung angezeigt, die Sie in der Abfrage angegeben haben.
Wenn Sie möchten, dass eine Abfrage fehlschlägt, wenn ein in der DML-Abfrage angegebener Spaltenname nicht mit dem Spaltennamen im Glue-Datenkatalog übereinstimmt, können Sie festlegen`spark.sql.caseSensitive=true`.
# Überlegungen zu Amazon EMR mit Lake Formation
Amazon EMR mit Lake Formation ist in allen verfügbaren [Regionen verfügbar](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-region.html).
## Überlegungen zu Amazon EMR mit Lake Formation für Version 7.9 und früher
Beachten Sie bei der Verwendung mit AWS Lake Formation EMR 7.9 und früheren Versionen Folgendes.
+ [Differenzierte Zugriffskontrolle](emr-lf-enable.md#emr-lf-fgac-perms) auf Zeilen-, Spalten- und Zellenebene ist auf Clustern mit Amazon-EMR-Versionen 6.15 und höher verfügbar.
+ Benutzer mit Zugriff auf eine Tabelle können auf alle Eigenschaften dieser Tabelle zugreifen. Wenn Sie eine auf Lake Formation basierende Zugriffskontrolle für eine Tabelle haben, überprüfen Sie die Tabelle, um sicherzustellen, dass die Eigenschaften keine vertraulichen Daten oder Informationen enthalten.
+ Amazon-EMR-Cluster mit Lake Formation unterstützen den Fallback von Spark auf HDFS nicht, wenn Spark Tabellenstatistiken sammelt. Dies trägt normalerweise zur Optimierung der Abfrageleistung bei.
+ Zu den Vorgängen, die Zugriffskontrollen auf der Grundlage von Lake Formation mit nicht verwalteten Apache-Spark-Tabellen unterstützen, gehören `INSERT INTO` und `INSERT OVERWRITE`.
+ Zu den Vorgängen, die auf Lake Formation mit Apache Spark und Apache Hive basierende Zugriffskontrollen unterstützen `SELECT`, `DESCRIBE`, `SHOW DATABASE`, `SHOW TABLE`, `SHOW COLUMN` und `SHOW PARTITION`.
+ Amazon EMR unterstützt keine Zugriffskontrolle auf die folgenden auf Lake Formation basierenden Vorgänge:
+ Schreibt in geregelte Tabellen
+ Amazon EMR unterstützt `CREATE TABLE` nicht. Amazon EMR 6.10.0 und höher unterstützt `ALTER TABLE`.
+ Andere DML-Anweisungen als `INSERT`-Befehle.
+ Es gibt Leistungsunterschiede zwischen derselben Abfrage mit und ohne Lake-Formation-basierte Zugriffskontrolle.
+ Sie können Amazon EMR nur mit Lake Formation für Spark-Jobs verwenden.
+ Die Weitergabe vertrauenswürdiger Identitäten wird bei einer Hierarchie mit mehreren Katalogen in Glue Data Catalog nicht unterstützt. Weitere Informationen finden Sie unter [Arbeiten mit einer Hierarchie mit mehreren Katalogen im AWS Glue-Datenkatalog](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-multi-catalog.html).
## Überlegungen zu Amazon EMR mit Lake Formation für Version 7.10 und höher
Beachten Sie Folgendes, wenn Sie Amazon EMR mit AWS Lake Formation EMR 7.10 und späteren Versionen verwenden.
+ Amazon EMR unterstützt eine differenzierte Zugriffskontrolle über Lake Formation nur für Apache Hive-, Apache Iceberg-, Apache Delta- und Apache Hudi-Tabellen. Zu den Apache Hive-Formaten gehören Parquet, ORC und xSV CSV.
+ Für Lake Formation Formation-fähige Anwendungen werden Spark-Protokolle in zwei Gruppen in Amazon S3 geschrieben: Systembereichsprotokolle und Benutzerbereichsprotokolle. Systembereichsprotokolle können vertrauliche Informationen wie das vollständige Tabellenschema enthalten. Um diese Daten zu schützen, speichert Amazon EMR Systemspeicherprotokolle an einem anderen Ort als Benutzerbereichsprotokolle. Es wird dringend empfohlen, dass Kontoadministratoren Benutzern keinen Zugriff auf Systemspeicherprotokolle gewähren.
+ Wenn Sie einen Tabellenstandort bei Lake Formation registrieren, wird der Datenzugriff ausschließlich durch die Berechtigungen der Rolle gesteuert, die für die Registrierung verwendet wurde, und nicht durch die Amazon EMR-Job-Runtime-Rolle. Wenn die Registrierungsrolle falsch konfiguriert ist, schlagen Jobs fehl, die versuchen, auf die Tabelle zuzugreifen.
+ `DynamicResourceAllocation`Für Jobs in Lake Formation kann man nicht abschalten.
+ Sie können Lake Formation nur mit Spark-Aufträgen verwenden.
+ Amazon EMR mit Lake Formation unterstützt nur eine einzige Spark-Sitzung während eines Jobs.
+ Amazon EMR 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
+ Amazon EMR 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 JARs für Spark-Erweiterungen, Connectors oder Metastore
+ `ANALYZE TABLE` command
+ Um Zugriffskontrollen, `EXPLAIN PLAN` und DDL-Vorgänge durchzusetzen, z. B. `DESCRIBE TABLE`, sollten eingeschränkte Informationen nicht offengelegt werden.
+ Amazon EMR schränkt den Zugriff auf Systemtreiber-Spark-Protokolle für Lake Formation-fähige Anwendungen ein. Da der Systemtreiber mit erhöhten Rechten 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, deaktiviert Amazon EMR den Zugriff auf Systemtreiberprotokolle.
Systemprofilprotokolle werden immer im verwalteten Speicher gespeichert — dies ist eine obligatorische Einstellung, die nicht deaktiviert werden kann. Diese Protokolle werden sicher gespeichert und entweder mit einem vom Kunden verwalteten KMS-Schlüssel oder einem AWS verwalteten KMS-Schlüssel verschlüsselt.
Wenn sich Ihre Amazon EMR-Anwendung in einem privaten Subnetz mit VPC-Endpunkten für Amazon S3 befindet und Sie eine Endpunktrichtlinie zur Zugriffskontrolle anhängen, müssen Sie, bevor Ihre Jobs Protokolldaten an AWS Managed Amazon S3 senden können, die unter Verwalteter [Speicher](logging.html#jobs-log-storage-managed-storage) beschriebenen Berechtigungen in Ihre VPC-Richtlinie für den S3-Gateway-Endpunkt aufnehmen. Wenden Sie sich bei Anfragen zur Fehlerbehebung an den Support. AWS
+ Wenn Sie einen Tabellenstandort bei Lake Formation registriert haben, durchläuft der Datenzugriffspfad unabhängig von der IAM-Berechtigung für die Amazon EMR-Job-Runtime-Rolle die gespeicherten Anmeldeinformationen von Lake Formation. Wenn Sie die mit dem Tabellenspeicherort registrierte Rolle falsch konfigurieren, schlagen gesendete Aufträge fehl, die die Rolle mit der S3-IAM-Berechtigung 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 Auftrag-Laufzeitrolle ü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.
## Überlegungen zu Amazon EMR mit Lake Formation für Version 7.12 und höher
### General
Beachten Sie die folgenden Einschränkungen bei der Verwendung von Lake Formation mit Amazon EMR.
+ `DynamicResourceAllocation`Für Jobs in Lake Formation kann man nicht abschalten.
+ Sie können Lake Formation nur mit Spark-Aufträgen verwenden.
+ Amazon EMR mit Lake Formation unterstützt nur eine einzige Spark-Sitzung während eines Jobs.
+ Amazon EMR 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
+ Zugriffskontrolle für verschachtelte Spalten
+ Amazon EMR 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 JARs für Spark-Erweiterungen, Connectors oder Metastore
+ `ANALYZE TABLE` command
+ Wenn sich Ihre Amazon EMR-Anwendung in einem privaten Subnetz mit VPC-Endpunkten für Amazon S3 befindet und Sie eine Endpunktrichtlinie zur Zugriffskontrolle anhängen, müssen Sie, bevor Ihre Jobs Protokolldaten an AWS Managed Amazon S3 senden können, die unter Verwalteter [Speicher](logging.html#jobs-log-storage-managed-storage) beschriebenen Berechtigungen in Ihre VPC-Richtlinie für den S3-Gateway-Endpunkt aufnehmen. Wenden Sie sich bei Anfragen zur Fehlerbehebung an den Support. AWS
+ Ab Amazon EMR 7.9.0 unterstützt Spark FGAC das AFile S3-System, wenn es mit dem s3a://-Schema verwendet wird.
+ Amazon EMR 7.11 unterstützt die Erstellung verwalteter Tabellen mithilfe von CTAS.
+ Amazon EMR 7.12 unterstützt die Erstellung verwalteter und externer Tabellen mithilfe von CTAS.
## Berechtigungen
+ Um Zugriffskontrollen durchzusetzen, geben EXPLAIN PLAN und DDL-Operationen wie DESCRIBE TABLE keine eingeschränkten Informationen preis.
+ Wenn Sie einen Tabellenstandort bei Lake Formation registrieren, verwendet der Datenzugriff die in Lake Formation gespeicherten Anmeldeinformationen anstelle der IAM-Berechtigungen der EMR-Serverless-Joblaufzeitrolle. Jobs schlagen fehl, wenn die registrierte Rolle für den Tabellenspeicherort falsch konfiguriert ist, auch wenn die Runtime-Rolle über S3-IAM-Berechtigungen für diesen Speicherort verfügt.
+ Ab Amazon EMR 7.12 können Sie mithilfe von DataFrameWriter (V2) mit Lake Formation Formation-Anmeldeinformationen im Anfügemodus in bestehende Hive- und Iceberg-Tabellen schreiben. Bei Überschreibvorgängen oder beim Erstellen neuer Tabellen verwendet EMR die Anmeldeinformationen der Runtime-Rolle, um Tabellendaten zu ändern.
+ Die folgenden Einschränkungen gelten, wenn Ansichten oder zwischengespeicherte Tabellen als Quelldaten verwendet werden (diese Einschränkungen gelten nicht für AWS Glue Data Catalog-Ansichten):
+ Für MERGE-, DELETE- und UPDATE-Operationen
+ Unterstützt: Verwenden von Ansichten und zwischengespeicherten Tabellen als Quelltabellen.
+ Nicht unterstützt: Verwendung von Ansichten und zwischengespeicherten Tabellen in Zuweisungs- und Bedingungsklauseln.
+ Für die Operationen CREATE OR REPLACE und REPLACE TABLE AS SELECT:
+ Nicht unterstützt: Verwenden von Ansichten und zwischengespeicherten Tabellen als Quelltabellen.
+ Delta Lake-Tabellen mit UDFs Quelldaten unterstützen MERGE-, DELETE- und UPDATE-Operationen nur, wenn der Löschvektor aktiviert ist.
## Protokolle und Debugging
+ Amazon EMR schränkt den Zugriff auf Systemtreiber-Spark-Protokolle für Lake Formation-fähige Anwendungen ein. Da der Systemtreiber mit erhöhten Rechten 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, deaktiviert Amazon EMR den Zugriff auf Systemtreiberprotokolle.
Systemprofilprotokolle werden immer im verwalteten Speicher gespeichert — dies ist eine obligatorische Einstellung, die nicht deaktiviert werden kann. Diese Protokolle werden sicher gespeichert und entweder mit einem vom Kunden verwalteten KMS-Schlüssel oder einem AWS verwalteten KMS-Schlüssel verschlüsselt.
## Iceberg
Beachten Sie die folgenden Überlegungen bei der Verwendung von Apache Iceberg:
+ 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 nicht in Lake Formation registriert sind, unterstützen alle gespeicherten Iceberg-Prozeduren. Die Prozeduren `register_table` und `migrate` werden für keine Tabellen unterstützt.
+ Wir empfehlen, Iceberg DataFrameWriter V2 anstelle von V1 zu verwenden.
# Die native, feinkörnige Zugriffskontrolle von Spark ist auf der untersten Liste PySpark
Um die Sicherheit und die Datenzugriffskontrollen aufrechtzuerhalten, schränkt Spark Fine-Grained Access Control (FGAC) bestimmte Funktionen ein. PySpark Diese Einschränkungen werden durchgesetzt durch:
+ Explizites Blockieren, das die Funktionsausführung verhindert
+ Architekturinkompatibilitäten, die Funktionen funktionsunfähig machen
+ Funktionen, die Fehler auslösen, Meldungen zurückgeben, bei denen der Zugriff verweigert wurde, oder die beim Aufruf nichts bewirken
Die folgenden PySpark Funktionen werden in Spark FGAC nicht unterstützt:
+ RDD-Operationen (mit Spark-Ausnahme blockiert) RDDUnsupported
+ Spark Connect (nicht unterstützt)
+ Spark Streaming (nicht unterstützt)
Wir haben die aufgelisteten Funktionen zwar in einer nativen Spark-FGAC-Umgebung getestet und bestätigt, dass sie erwartungsgemäß funktionieren, aber unsere Tests decken in der Regel nur die grundlegende Nutzung der einzelnen APIs ab. Für Funktionen mit mehreren Eingabetypen oder komplexen Logikpfaden gibt es möglicherweise noch nicht getestete Szenarien.
Für alle Funktionen, die hier nicht aufgeführt sind und nicht eindeutig zu den oben genannten, nicht unterstützten Kategorien gehören, empfehlen wir:
+ Testen Sie sie zuerst in einer Gamma-Umgebung oder in kleinem Maßstab
+ Überprüfung ihres Verhaltens, bevor sie in der Produktion eingesetzt werden
**Anmerkung**
Wenn eine Klassenmethode aufgeführt ist, aber nicht ihre Basisklasse, sollte die Methode trotzdem funktionieren. Das bedeutet nur, dass wir den Basisklassenkonstruktor nicht explizit verifiziert haben.
Die PySpark API ist in Module unterteilt. Die allgemeine Unterstützung für Methoden innerhalb der einzelnen Module ist in der folgenden Tabelle detailliert beschrieben.
| Module name (Modulname) | Status | Hinweise |
| --- | --- | --- |
| pyspark\$1core | Unterstützt | Dieses Modul enthält die wichtigsten RDD-Klassen, und diese Funktionen werden meistens nicht unterstützt. |
| pyspark\$1sql | Unterstützt | |
| pyspark\$1testing | Unterstützt | |
| pyspark\$1resource | Unterstützt | |
| pyspark\$1streaming | Blocked | Die Streaming-Nutzung ist in Spark FGAC blockiert. |
| pyspark\$1mllib | Experimentell | Dieses Modul enthält RDD-basierte ML-Operationen, und diese Funktionen werden größtenteils nicht unterstützt. Dieses Modul wurde nicht gründlich getestet. |
| pyspark\$1ml | Experimentell | Dieses Modul enthält DataFrame basierte ML-Operationen, und diese Funktionen werden größtenteils unterstützt. Dieses Modul wurde nicht gründlich getestet. |
| pyspark\$1pandas | Unterstützt | |
| pyspark\$1pandas\$1langsam | Unterstützt | |
| pyspark\$1connect | Blocked | Die Nutzung von Spark Connect ist in Spark FGAC blockiert. |
| pyspark\$1pandas\$1connect | Blocked | Die Nutzung von Spark Connect ist in Spark FGAC blockiert. |
| pyspark\$1pandas\$1slow\$1connect | Blocked | Die Nutzung von Spark Connect ist in Spark FGAC blockiert. |
| pyspark\$1errors | Experimentell | Dieses Modul wurde nicht gründlich getestet. Benutzerdefinierte Fehlerklassen können nicht verwendet werden. |
**API-Zulassungsliste**
Für eine herunterladbare und einfacher zu durchsuchende Liste ist eine Datei mit den Modulen und Klassen unter [Python-Funktionen verfügbar, die in Native FGAC erlaubt](samples/Python functions allowed in Native FGAC.zip) sind.
# Lake Formation Vollzugriff auf Tabellen für Amazon EMR auf EC2
Mit den Amazon EMR-Versionen 7.8.0 und höher können Sie AWS Lake Formation mit Glue Data Catalog nutzen, wobei die Job-Runtime-Rolle über vollständige Tabellenberechtigungen verfügt, ohne die Einschränkungen einer detaillierten Zugriffskontrolle. Diese Funktion ermöglicht Ihnen das Lesen und Schreiben in Tabellen, die durch Lake Formation geschützt sind, von Ihrem Amazon EMR auf EC2 Spark-Batch- und interaktiven Jobs aus. In den folgenden Abschnitten erfahren Sie mehr über Lake Formation und dessen Verwendung mit Amazon EMR auf EC2.
## Lake Formation mit vollständigem Tabellenzugriff verwenden
Sie können auf AWS Lake Formation Formation-geschützte Glue Data-Katalogtabellen von Amazon EMR auf EC2 Spark-Jobs oder interaktive Sitzungen zugreifen, bei denen die Runtime-Rolle des Jobs vollen Tabellenzugriff hat. Sie müssen AWS Lake Formation in der Amazon EMR on EC2-Anwendung nicht aktivieren. Wenn ein Spark-Job für Full Table Access (FTA) konfiguriert ist, werden AWS Lake Formation-Anmeldeinformationen für read/write S3-Daten für in AWS Lake Formation registrierte Tabellen verwendet, während die Anmeldeinformationen für die Laufzeitrolle des Jobs für read/write Tabellen verwendet werden, die nicht bei AWS Lake Formation registriert sind.
**Wichtig**
Aktivieren Sie AWS Lake Formation nicht für eine detaillierte Zugriffskontrolle. Ein Job kann nicht gleichzeitig Full Table Access (FTA) und Fine-Grained Access Control (FGAC) auf demselben EMR-Cluster oder derselben EMR-Applikation ausführen.
### Schritt 1: Vollständigen Tabellenzugriff in Lake Formation aktivieren
Um den Modus Full Table Access (FTA) zu verwenden, müssen Sie Drittanbieter-Abfrage-Engines den Zugriff auf Daten ohne die IAM-Sitzungs-Tag-Validierung in AWS Lake Formation gestatten. Folgen Sie zur Aktivierung den Schritten unter [Application integration for full table access](https://docs.aws.amazon.com/lake-formation/latest/dg/full-table-credential-vending.html).
**Anmerkung**
Beim Zugriff auf kontenübergreifende Tabellen muss der Zugriff auf vollständige Tabellen sowohl in Producer- als auch in Consumer-Konten aktiviert sein. Ebenso muss diese Einstellung beim Zugriff auf regionsübergreifende Tabellen sowohl in Erzeuger- als auch in Verbraucherregionen aktiviert sein.
### Schritt 2: Einrichten der IAM-Berechtigungen für die Auftrag-Laufzeitrolle
Für den Lese- oder Schreibzugriff auf zugrunde liegende Daten benötigt eine Job-Runtime-Rolle zusätzlich zu den Lake Formation Formation-Berechtigungen die `lakeformation:GetDataAccess` IAM-Berechtigung. Mit dieser Berechtigung gewährt Lake Formation die Anforderung von temporären Anmeldeinformationen für den Zugriff auf die Daten.
Im Folgenden finden Sie eine Beispielrichtlinie für die Bereitstellung von IAM-Berechtigungen für den Zugriff auf ein Skript in Amazon S3, für das Hochladen von Protokollen auf S3, für AWS Glue-API-Berechtigungen und für den Zugriff auf Lake Formation.
#### Schritt 2.1 Lake Formation Formation-Berechtigungen konfigurieren
+ Spark-Jobs, die Daten aus S3 lesen, benötigen die Lake Formation SELECT-Berechtigung.
+ Spark-Jobs, für die write/delete Daten in S3 ist die Lake Formation ALL (SUPER) -Genehmigung erforderlich.
+ Spark-Jobs, die mit dem Glue-Datenkatalog interagieren, benötigen die entsprechenden DESCRIBE-, ALTER- und DROP-Berechtigungen.
Weitere Informationen finden Sie unter [Erteilen von Berechtigungen für Datenkatalogressourcen](https://docs.aws.amazon.com/lake-formation/latest/dg/granting-catalog-permissions.html).
### Schritt 3: Initialisieren Sie eine Spark-Sitzung für den vollständigen Tabellenzugriff mit Lake Formation
#### Voraussetzungen
AWS Der Glue Data Catalog muss als Metastore konfiguriert werden, um auf Lake Formation-Tabellen zugreifen zu können.
Legen Sie die folgenden Einstellungen fest, um den Glue-Katalog als Metastore zu konfigurieren:
```
--conf spark.sql.catalogImplementation=hive
--conf spark.hive.metastore.client.factory.class=com.amazonaws.glue.catalog.metastore.AWSGlueDataCatalogHiveClientFactory
```
Weitere Informationen zur Aktivierung von Data Catalog for Amazon EMR auf EC2 finden Sie unter [Metastore-Konfiguration für Amazon EMR](metastore-config.html) auf EC2.
Um auf Tabellen zuzugreifen, die bei AWS Lake Formation registriert sind, müssen die folgenden Konfigurationen während der Spark-Initialisierung festgelegt werden, um Spark für die Verwendung von AWS Lake Formation Formation-Anmeldeinformationen zu konfigurieren.
------
#### [ Hive ]
```
‐‐conf spark.hadoop.fs.s3.credentialsResolverClass=com.amazonaws.glue.accesscontrol.AWSLakeFormationCredentialResolver
--conf spark.hadoop.fs.s3.useDirectoryHeaderAsFolderObject=true
--conf spark.hadoop.fs.s3.folderObject.autoAction.disabled=true
--conf spark.sql.catalog.skipLocationValidationOnCreateTable.enabled=true
--conf spark.sql.catalog.createDirectoryAfterTable.enabled=true
--conf spark.sql.catalog.dropDirectoryBeforeTable.enabled=true
```
------
#### [ Iceberg ]
```
--conf spark.sql.catalog.spark_catalog=org.apache.iceberg.spark.SparkSessionCatalog
--conf spark.sql.catalog.spark_catalog.warehouse=S3_DATA_LOCATION
--conf spark.sql.catalog.spark_catalog.client.region=REGION
--conf spark.sql.catalog.spark_catalog.type=glue
--conf spark.sql.catalog.spark_catalog.glue.account-id=ACCOUNT_ID
--conf spark.sql.catalog.spark_catalog.glue.lakeformation-enabled=true
--conf spark.sql.catalog.dropDirectoryBeforeTable.enabled=true
```
------
#### [ Delta Lake ]
```
‐‐conf spark.hadoop.fs.s3.credentialsResolverClass=com.amazonaws.glue.accesscontrol.AWSLakeFormationCredentialResolver
--conf spark.hadoop.fs.s3.useDirectoryHeaderAsFolderObject=true
--conf spark.hadoop.fs.s3.folderObject.autoAction.disabled=true
--conf spark.sql.catalog.skipLocationValidationOnCreateTable.enabled=true
--conf spark.sql.catalog.createDirectoryAfterTable.enabled=true
--conf spark.sql.catalog.dropDirectoryBeforeTable.enabled=true
```
------
#### [ Hudi ]
```
‐‐conf spark.hadoop.fs.s3.credentialsResolverClass=com.amazonaws.glue.accesscontrol.AWSLakeFormationCredentialResolver
--conf spark.hadoop.fs.s3.useDirectoryHeaderAsFolderObject=true
--conf spark.hadoop.fs.s3.folderObject.autoAction.disabled=true
--conf spark.sql.catalog.skipLocationValidationOnCreateTable.enabled=true
--conf spark.sql.catalog.createDirectoryAfterTable.enabled=true
--conf spark.sql.catalog.dropDirectoryBeforeTable.enabled=true
--conf spark.jars=/usr/lib/hudi/hudi-spark-bundle.jar
--conf spark.sql.extensions=org.apache.spark.sql.hudi.HoodieSparkSessionExtension
--conf spark.sql.catalog.spark_catalog=org.apache.spark.sql.hudi.catalog.HoodieCatalog
--conf spark.serializer=org.apache.spark.serializer.KryoSerializer
```
------
+ `spark.hadoop.fs.s3.credentialsResolverClass=com.amazonaws.glue.accesscontrol.AWSLakeFormationCredentialResolver`: Konfigurieren Sie EMR Filesystem (EMRFS) oder EMR S3A so, dass Lake Formation S3-Anmeldeinformationen für registrierte AWS Lake Formation-Tabellen verwendet werden. Wenn die Tabelle nicht registriert ist, verwenden Sie die Anmeldeinformationen für die Auftrag-Laufzeitrolle.
+ `spark.hadoop.fs.s3.useDirectoryHeaderAsFolderObject=true` und `spark.hadoop.fs.s3.folderObject.autoAction.disabled=true`: Konfigurieren Sie EMRFS so, dass beim Erstellen von S3-Ordnern der Content-Type-Header „application/x-directory“ anstelle des Suffixes „\$1folder\$1“ verwendet wird. Dies ist beim Lesen von Lake Formation-Tabellen erforderlich, da die Anmeldeinformationen von Lake Formation das Lesen von Tabellenordnern mit dem Suffix \$1folder\$1 nicht zulassen.
+ `spark.sql.catalog.skipLocationValidationOnCreateTable.enabled=true`: Konfigurieren Sie Spark so, dass die Überprüfung, ob der Tabellenspeicherort leer ist, vor der Erstellung übersprungen wird. Dies ist für in Lake Formation registrierte Tabellen erforderlich, da die Anmeldeinformationen für Lake Formation zur Überprüfung des leeren Speicherorts erst nach der Erstellung der Glue Data Catalog-Tabelle verfügbar sind. Ohne diese Konfiguration validieren die Anmeldeinformationen für die Auftrag-Laufzeitrolle den Speicherort der leeren Tabelle.
+ `spark.sql.catalog.createDirectoryAfterTable.enabled=true`: Konfigurieren Sie Spark so, dass der Amazon-S3-Ordner nach der Tabellenerstellung im Hive-Metastore erstellt wird. Dies ist für in Lake Formation registrierte Tabellen erforderlich, da die Anmeldeinformationen für Lake Formation zum Erstellen des S3-Ordners erst nach der Erstellung der Glue Data Catalog-Tabelle verfügbar sind.
+ `spark.sql.catalog.dropDirectoryBeforeTable.enabled=true`: Konfigurieren Sie Spark so, dass der S3-Ordner vor dem Löschen der Tabelle im Hive-Metastore gelöscht wird. Dies ist für in Lake Formation registrierte Tabellen erforderlich, da die Lake Formation Formation-Anmeldeinformationen zum Löschen des S3-Ordners nach dem Löschen der Tabelle aus dem Glue-Datenkatalog nicht verfügbar sind.
+ `spark.sql.catalog..glue.lakeformation-enabled=true`: Konfigurieren Sie den Iceberg-Katalog so, dass er AWS Lake Formation S3-Anmeldeinformationen für registrierte Lake Formation-Tabellen verwendet. Wenn die Tabelle nicht registriert ist, verwenden Sie die Standardanmeldeinformationen für die Umgebung.
#### Konfigurieren Sie den vollständigen Tabellenzugriffsmodus in SageMaker Unified Studio
Verwenden Sie den Kompatibilitätsberechtigungsmodus, um über interaktive Spark-Sitzungen in JupyterLab Notebooks auf registrierte Tabellen von Lake Formation zuzugreifen. Verwenden Sie den magischen Befehl %%configure, um Ihre Spark-Konfiguration einzurichten. Wählen Sie die Konfiguration basierend auf Ihrem Tabellentyp aus:
------
#### [ For Hive tables ]
```
%%configure -f
{
"conf": {
"spark.hadoop.fs.s3.credentialsResolverClass": "com.amazonaws.glue.accesscontrol.AWSLakeFormationCredentialResolver",
"spark.hadoop.fs.s3.useDirectoryHeaderAsFolderObject": true,
"spark.hadoop.fs.s3.folderObject.autoAction.disabled": true,
"spark.sql.catalog.skipLocationValidationOnCreateTable.enabled": true,
"spark.sql.catalog.createDirectoryAfterTable.enabled": true,
"spark.sql.catalog.dropDirectoryBeforeTable.enabled": true
}
}
```
------
#### [ For Iceberg tables ]
```
%%configure -f
{
"conf": {
"spark.sql.catalog.spark_catalog": "org.apache.iceberg.spark.SparkSessionCatalog",
"spark.sql.catalog.spark_catalog.warehouse": "S3_DATA_LOCATION",
"spark.sql.catalog.spark_catalog.client.region": "REGION",
"spark.sql.catalog.spark_catalog.type": "glue",
"spark.sql.catalog.spark_catalog.glue.account-id": "ACCOUNT_ID",
"spark.sql.catalog.spark_catalog.glue.lakeformation-enabled": "true",
"spark.sql.catalog.dropDirectoryBeforeTable.enabled": "true",
}
}
```
------
#### [ For Delta Lake tables ]
```
%%configure -f
{
"conf": {
"spark.hadoop.fs.s3.credentialsResolverClass": "com.amazonaws.glue.accesscontrol.AWSLakeFormationCredentialResolver",
"spark.hadoop.fs.s3.useDirectoryHeaderAsFolderObject": true,
"spark.hadoop.fs.s3.folderObject.autoAction.disabled": true,
"spark.sql.catalog.skipLocationValidationOnCreateTable.enabled": true,
"spark.sql.catalog.createDirectoryAfterTable.enabled": true,
"spark.sql.catalog.dropDirectoryBeforeTable.enabled": true
}
}
```
------
#### [ For Hudi tables ]
```
%%configure -f
{
"conf": {
"spark.hadoop.fs.s3.credentialsResolverClass": "com.amazonaws.glue.accesscontrol.AWSLakeFormationCredentialResolver",
"spark.hadoop.fs.s3.useDirectoryHeaderAsFolderObject": true,
"spark.hadoop.fs.s3.folderObject.autoAction.disabled": true,
"spark.sql.catalog.skipLocationValidationOnCreateTable.enabled": true,
"spark.sql.catalog.createDirectoryAfterTable.enabled": true,
"spark.sql.catalog.dropDirectoryBeforeTable.enabled": true,
"spark.jars": "/usr/lib/hudi/hudi-spark-bundle.jar",
"spark.sql.extensions": "org.apache.spark.sql.hudi.HoodieSparkSessionExtension",
"spark.sql.catalog.spark_catalog": "org.apache.spark.sql.hudi.catalog.HoodieCatalog",
"spark.serializer": "org.apache.spark.serializer.KryoSerializer"
}
}
```
------
Ersetzen Sie die Platzhalter:
+ `S3_DATA_LOCATION`: Ihr S3-Bucket-Pfad
+ `REGION`: AWS Region (z. B. us-east-1)
+ `ACCOUNT_ID`: Ihre Konto-ID AWS
**Anmerkung**
Sie müssen diese Konfigurationen festlegen, bevor Sie Spark-Operationen in Ihrem Notebook ausführen.
#### Unterstützte Vorgänge
Bei diesen Vorgängen werden AWS Lake Formation Formation-Anmeldeinformationen für den Zugriff auf die Tabellendaten verwendet.
+ CREATE TABLE
+ ALTER TABLE
+ INSERT INTO
+ INSERT OVERWRITE
+ UPDATE
+ MERGE INTO
+ DELETE FROM
+ ANALYZE TABLE
+ REPAIR TABLE
+ DROP TABLE
+ Spark-Datenquellenabfragen
+ Spark-Datenquellenschreibvorgänge
**Anmerkung**
Operationen, die oben nicht aufgeführt sind, verwenden weiterhin IAM-Berechtigungen für den Zugriff auf Tabellendaten.
#### Überlegungen
+ Wenn eine Hive-Tabelle mit einem Job erstellt wird, für den der vollständige Tabellenzugriff nicht aktiviert ist, und keine Datensätze eingefügt werden, schlagen nachfolgende Lese- oder Schreibvorgänge aus einem Job mit vollständigem Tabellenzugriff fehl. Dies liegt daran, dass EMR Spark ohne vollständigen Tabellenzugriff das `$folder$` Suffix zum Namen des Tabellenordners hinzufügt. Um dieses Problem zu lösen, haben Sie folgende Möglichkeiten:
+ Fügen Sie mindestens eine Zeile aus einem Auftrag in die Tabelle ein, für den FTA nicht aktiviert ist.
+ Konfigurieren Sie den Job, für den FTA nicht aktiviert ist, so, dass er in S3 kein `$folder$` Suffix im Ordnernamen verwendet. Dies kann durch Einstellen der Spark-Konfiguration `spark.hadoop.fs.s3.useDirectoryHeaderAsFolderObject=true` erreicht werden.
+ Erstellen Sie mit der S3-Konsole oder AWS der S3-CLI einen AWS S3-Ordner am Speicherort `s3://path/to/table/table_name` der Tabelle.
+ Vollständiger Tabellenzugriff wird mit dem EMR-Dateisystem (EMRFS) ab Amazon EMR-Version 7.8.0 und mit dem S3A-Dateisystem ab Amazon EMR-Version 7.10.0 unterstützt.
+ Full Table Access wird für Hive-, Iceberg-, Delta- und Hudi-Tabellen unterstützt.
+ **Überlegungen zum Hudi FTA Write Support:**
+ Hudi FTA-Schreibvorgänge müssen HoodieCredentialedHadoopStorage für den Verkauf von Anmeldeinformationen während der Auftragsausführung verwendet werden. Stellen Sie die folgende Konfiguration ein, wenn Sie Hudi-Jobs ausführen: `hoodie.storage.class=org.apache.spark.sql.hudi.storage.HoodieCredentialedHadoopStorage`
+ Full Table Access (FTA) -Schreibunterstützung für Hudi ist ab Amazon EMR Version 7.12 verfügbar.
+ Die Hudi FTA-Schreibunterstützung funktioniert derzeit nur mit den Hudi-Standardkonfigurationen. Benutzerdefinierte oder nicht standardmäßige Hudi-Einstellungen werden möglicherweise nicht vollständig unterstützt und können zu unerwartetem Verhalten führen.
+ Clustering für Hudi-Tabellen Merge-On-Read (MOR) wird derzeit im FTA-Schreibmodus nicht unterstützt.
+ Jobs, die auf Tabellen mit Lake Formation Fine-Grained Access Control (FGAC) -Regeln oder Glue Data Catalog Views verweisen, schlagen fehl. Um eine Tabelle mit FGAC-Regeln oder einer Glue-Datenkatalogsicht abzufragen, müssen Sie den FGAC-Modus verwenden. Sie können den FGAC-Modus aktivieren, indem Sie die in der AWS Dokumentation beschriebenen Schritte ausführen: [Verwenden von Amazon EMR auf EC2 mit AWS Lake Formation für](emr-serverless-lf-enable.html) eine detaillierte Zugriffskontrolle.
+ Der vollständige Tabellenzugriff unterstützt Spark Streaming nicht.
+ Beim Schreiben von Spark DataFrame in eine Lake Formation-Tabelle wird nur der APPEND-Modus für Hive- und Iceberg-Tabellen unterstützt: `df.write.mode("append").saveAsTable(table_name)`
+ Für das Erstellen externer Tabellen sind IAM-Berechtigungen erforderlich.
+ Da Lake Formation Anmeldeinformationen vorübergehend innerhalb eines Spark-Jobs zwischenspeichert, spiegelt ein Spark-Batchjob oder eine interaktive Sitzung, die gerade ausgeführt wird, möglicherweise keine Berechtigungsänderungen wider.
+ Sie müssen eine benutzerdefinierte Rolle und keine dienstverknüpfte Rolle verwenden: [Lake Formation Formation-Anforderungen für Rollen](https://docs.aws.amazon.com/lake-formation/latest/dg/registration-role.html).
#### Hudi FTA Write Support - Unterstützte Operationen
Die folgende Tabelle zeigt die unterstützten Schreibvorgänge für Hudi- Copy-On-Write (COW) - und Merge-On-Read (MOR) -Tabellen im Modus „Vollständiger Tabellenzugriff“:
**Von Hudi FTA unterstützte Schreibvorgänge**
| Tabellentyp | Operation | SQL Write-Befehl | Status |
| --- | --- | --- | --- |
| KUH | INSERT | INSERT INTO TABLE | Unterstützt |
| KUH | INSERT | IN TABELLE EINFÜGEN — PARTITION (statisch, dynamisch) | Unterstützt |
| KUH | INSERT | INSERT OVERWRITE | Unterstützt |
| KUH | INSERT | INSERT OVERWRITE - PARTITION (statisch, dynamisch) | Unterstützt |
| UPDATE | UPDATE | UPDATE TABLE | Unterstützt |
| KUH | UPDATE | TABELLE AKTUALISIEREN — Partition ändern | Nicht unterstützt |
| DELETE | DELETE | DELETE FROM TABLE | Unterstützt |
| ALTER | ALTER | TABELLE ÄNDERN - UMBENENNEN IN | Nicht unterstützt |
| KUH | ALTER | TABELLE ÄNDERN - TABELLENEIGENSCHAFTEN FESTLEGEN | Unterstützt |
| KUH | ALTER | TABELLE ÄNDERN - TBLPROPERTIES DEAKTIVIEREN | Unterstützt |
| KUH | ALTER | TABELLE ÄNDERN - SPALTE ÄNDERN | Unterstützt |
| KUH | ALTER | TABELLE ÄNDERN - SPALTEN HINZUFÜGEN | Unterstützt |
| KUH | ALTER | TABELLE ÄNDERN - PARTITION HINZUFÜGEN | Unterstützt |
| KUH | ALTER | TABELLE ÄNDERN - PARTITION LÖSCHEN | Unterstützt |
| KUH | ALTER | TABELLE ÄNDERN - PARTITIONEN WIEDERHERSTELLEN | Unterstützt |
| KUH | ALTER | REPARIERE TABELLENSYNCHRONISIERUNGSPARTITIONEN | Unterstützt |
| DROP | DROP | DROP TABLE | Unterstützt |
| KUH | DROP | TABELLE LÖSCHEN - LÖSCHEN | Unterstützt |
| CREATE | CREATE | TABELLE ERSTELLEN — Verwaltet | Unterstützt |
| KUH | CREATE | TABELLE ERSTELLEN - PARTITIONIEREN NACH | Unterstützt |
| KUH | CREATE | TABELLE ERSTELLEN, FALLS NICHT VORHANDEN | Unterstützt |
| KUH | CREATE | CREATE TABLE LIKE | Unterstützt |
| KUH | CREATE | CREATE TABLE AS SELECT | Unterstützt |
| CREATE | CREATE | TABELLE MIT STANDORT ERSTELLEN — Externe Tabelle | Nicht unterstützt |
| DATENRAHMEN (EINFÜGEN) | DATENRAHMEN (EINFÜGEN) | saveAsTable. Überschreiben | Unterstützt |
| KUH | DATENRAHMEN (EINFÜGEN) | saveAsTable. Anhängen | Nicht unterstützt |
| KUH | DATENRAHMEN (EINFÜGEN) | saveAsTable. Ignorieren | Unterstützt |
| KUH | DATENRAHMEN (EINFÜGEN) | saveAsTable.ErrorIfExists | Unterstützt |
| KUH | DATENRAHMEN (EINFÜGEN) | saveAsTable - Externe Tabelle (Pfad) | Nicht unterstützt |
| KUH | DATENRAHMEN (EINFÜGEN) | speichern (Pfad) — DF v1 | Nicht unterstützt |
| MEHR | INSERT | INSERT INTO TABLE | Unterstützt |
| MEHR | INSERT | IN TABELLE EINFÜGEN — PARTITION (statisch, dynamisch) | Unterstützt |
| MEHR | INSERT | INSERT OVERWRITE | Unterstützt |
| MEHR | INSERT | INSERT OVERWRITE - PARTITION (statisch, dynamisch) | Unterstützt |
| UPDATE | UPDATE | UPDATE TABLE | Unterstützt |
| MEHR | UPDATE | TABELLE AKTUALISIEREN — Partition ändern | Nicht unterstützt |
| DELETE | DELETE | DELETE FROM TABLE | Unterstützt |
| ALTER | ALTER | TABELLE ÄNDERN - UMBENENNEN IN | Nicht unterstützt |
| MEHR | ALTER | TABELLE ÄNDERN - TABELLENEIGENSCHAFTEN FESTLEGEN | Unterstützt |
| MEHR | ALTER | TABELLE ÄNDERN - TABELLENEIGENSCHAFTEN DEAKTIVIEREN | Unterstützt |
| MEHR | ALTER | TABELLE ÄNDERN - SPALTE ÄNDERN | Unterstützt |
| MEHR | ALTER | TABELLE ÄNDERN - SPALTEN HINZUFÜGEN | Unterstützt |
| MEHR | ALTER | TABELLE ÄNDERN - PARTITION HINZUFÜGEN | Unterstützt |
| MEHR | ALTER | TABELLE ÄNDERN - PARTITION LÖSCHEN | Unterstützt |
| MEHR | ALTER | TABELLE ÄNDERN - PARTITIONEN WIEDERHERSTELLEN | Unterstützt |
| MEHR | ALTER | REPARIERE TABELLENSYNCHRONISIERUNGSPARTITIONEN | Unterstützt |
| DROP | DROP | DROP TABLE | Unterstützt |
| MEHR | DROP | TABELLE LÖSCHEN - LÖSCHEN | Unterstützt |
| CREATE | CREATE | TABELLE ERSTELLEN — Verwaltet | Unterstützt |
| MEHR | CREATE | TABELLE ERSTELLEN - PARTITIONIEREN NACH | Unterstützt |
| MEHR | CREATE | TABELLE ERSTELLEN, FALLS NICHT VORHANDEN | Unterstützt |
| MEHR | CREATE | CREATE TABLE LIKE | Unterstützt |
| MEHR | CREATE | CREATE TABLE AS SELECT | Unterstützt |
| CREATE | CREATE | TABELLE MIT STANDORT ERSTELLEN - Externe Tabelle | Nicht unterstützt |
| DATENRAHMEN (UPSERT) | DATENRAHMEN (UPSERT) | saveAsTable. Überschreiben | Unterstützt |
| MEHR | DATENRAHMEN (VERÄRGERT) | saveAsTable. Anhängen | Nicht unterstützt |
| MEHR | DATENRAHMEN (VERÄRGERT) | saveAsTable. Ignorieren | Unterstützt |
| MEHR | DATENRAHMEN (VERÄRGERT) | saveAsTable.ErrorIfExists | Unterstützt |
| MEHR | DATENRAHMEN (VERÄRGERT) | saveAsTable - Externe Tabelle (Pfad) | Nicht unterstützt |
| MEHR | DATENRAHMEN (VERÄRGERT) | speichern (Pfad) — DF v1 | Nicht unterstützt |
| DATENRAHMEN (LÖSCHEN) | DATENRAHMEN (LÖSCHEN) | saveAsTable. Anhängen | Nicht unterstützt |
| MEHR | DATENRAHMEN (LÖSCHEN) | saveAsTable - Externe Tabelle (Pfad) | Nicht unterstützt |
| MEHR | DATENRAHMEN (LÖSCHEN) | speichern (Pfad) — DF v1 | Nicht unterstützt |
| DATENRAHMEN (BULK\$1INSERT) | DATENRAHMEN (BULK\$1INSERT) | saveAsTable. Überschreiben | Unterstützt |
| MEHR | DATENRAHMEN (BULK\$1INSERT) | saveAsTable. Anhängen | Nicht unterstützt |
| MEHR | DATENRAHMEN (BULK\$1INSERT) | saveAsTable. Ignorieren | Unterstützt |
| MEHR | DATENRAHMEN (BULK\$1INSERT) | saveAsTable.ErrorIfExists | Unterstützt |
| MEHR | DATENRAHMEN (BULK\$1INSERT) | saveAsTable - Externe Tabelle (Pfad) | Nicht unterstützt |
| MEHR | DATENRAHMEN (BULK\$1INSERT) | speichern (Pfad) — DF v1 | Nicht unterstützt |
# Integrieren Sie Amazon EMR mit Apache Ranger
Mit Amazon EMR 5.32.0 können Sie einen Cluster starten, der nativ in Apache Ranger integriert ist. Apache Ranger ist ein Open-Source-Framework zur Aktivierung, Überwachung und Verwaltung einer umfassenden Datensicherheit auf der gesamten Hadoop-Plattform. Weitere Informationen finden Sie unter [Apache Ranger](https://ranger.apache.org/). Dank der nativen Integration können Sie Ihren eigenen Apache Ranger verwenden, um eine detaillierte Datenzugriffskontrolle auf Amazon EMR durchzusetzen.
Dieser Abschnitt bietet eine konzeptionelle Übersicht über die Amazon-EMR-Integration in Apache Ranger. Außerdem werden die Voraussetzungen und Schritte zum Starten eines in Apache Ranger integrierten Amazon-EMR-Clusters beschrieben.
Die native Integration von Amazon EMR mit Apache Ranger bietet die folgenden Hauptvorteile:
+ Präzise Zugriffskontrolle für Hive Metastore-Datenbanken und -Tabellen, mit der Sie Datenfilterungsrichtlinien auf Datenbank-, Tabellen- und Spaltenebene für Apache Spark- und Apache Hive-Anwendungen definieren können. Filterung und Datenmaskierung auf Zeilenebene werden von Hive-Anwendungen unterstützt.
+ Die Möglichkeit, Ihre bestehenden Hive-Richtlinien direkt mit Amazon EMR for Hive-Anwendungen zu verwenden.
+ Zugriffskontrolle auf Amazon S3-Daten auf Präfix- und Objektebene, sodass Sie Datenfilterrichtlinien für den Zugriff auf S3-Daten mithilfe des EMR-Dateisystems definieren können.
+ Die Möglichkeit, CloudWatch Logs für zentralisierte Audits zu verwenden.
+ Amazon EMR installiert und verwaltet die Apache Ranger-Plugin Ihrem Namen.
# Apache Ranger mit Amazon EMR
Apache Ranger ist ein Framework zur Aktivierung, Überwachung und Verwaltung einer umfassenden Datensicherheit auf der gesamten Hadoop-Plattform.
Apache Ranger bietet folgende Features:
+ Zentralisierte Sicherheitsadministration zur Verwaltung aller sicherheitsrelevanten Aufgaben in einer zentralen Benutzeroberfläche oder mithilfe von REST. APIs
+ Detaillierte Autorisierung zur Durchführung einer bestimmten Aktion oder Operation mit einer Hadoop-Komponente oder einem Hadoop-Tool, die über ein zentrales Administrationstool verwaltet wird.
+ Eine standardisierte Autorisierungsmethode für alle Hadoop-Komponenten.
+ Verbesserte Unterstützung für verschiedene Autorisierungsmethoden.
+ Zentralisierte Prüfung des Benutzerzugriffs und der administrativen Aktionen (sicherheitsbezogen) innerhalb aller Komponenten von Hadoop.
Apache Ranger verwendet zwei Schlüsselkomponenten für die Autorisierung:
+ **Apache-Ranger-Richtlinien-Admin-Server** – Mit diesem Server können Sie die Autorisierungsrichtlinien für Hadoop-Anwendungen definieren. Bei der Integration mit Amazon EMR können Sie Richtlinien für Apache Spark und Hive für den Zugriff auf Hive Metastore und für den Zugriff auf Amazon-S3-Daten im [EMR File System (EMRFS)](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-fs) definieren und durchsetzen. Sie können einen neuen Apache-Ranger-Richtlinien-Admin-Server einrichten oder einen vorhandenen Apache-Ranger-Richtlinien-Admin-Server für die Integration mit Amazon EMR verwenden.
+ **Apache-Ranger-Plugin** – Dieses Plugin validiert den Zugriff eines Benutzers anhand der Autorisierungsrichtlinien, die im Apache-Ranger-Richtlinien-Admin-Server definiert sind. Amazon EMR installiert und konfiguriert das Apache-Ranger-Plugin automatisch für jede Hadoop-Anwendung, die in der Apache-Ranger-Konfiguration ausgewählt wurde.
**Topics**
+ [Architektur der Amazon-EMR-Integration mit Apache Ranger](emr-ranger-architecture.md)
+ [Amazon EMR-Komponenten zur Verwendung mit Apache Ranger](emr-ranger-components.md)
# Architektur der Amazon-EMR-Integration mit Apache Ranger
![\[Architekturdiagramm von Amazon EMR und Apache Ranger.\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/images/emr-ranger-architecture.png)
# Amazon EMR-Komponenten zur Verwendung mit Apache Ranger
Amazon EMR ermöglicht eine differenzierte Zugriffskontrolle mit Apache Ranger über die folgenden Komponenten. Im [Architekturdiagramm](emr-ranger-architecture.md) finden Sie eine visuelle Darstellung dieser Amazon-EMR-Komponenten mit den Apache-Ranger-Plugins.
**Secret-Agent** – Der Secret-Agent speichert geheime Daten sicher und verteilt sie an andere Amazon-EMR-Komponenten oder Anwendungen. Bei diesen geheimen Daten („Secrets“) kann es sich beispielsweise um temporäre Anmeldeinformationen von Benutzern, um Verschlüsselungsschlüssel oder um Kerberos-Tickets handeln. Der Secret Agent läuft auf jedem Knoten im Cluster und fängt Aufrufe an den Instance Metadata Service ab. Für Anfragen an die Rollenanmeldedaten des Instance-Profils vergibt der Secret Agent je nach dem anfragenden Benutzer und den angeforderten Ressourcen Anmeldeinformationen, nachdem er die Anfrage mit dem EMRFS-S3-Ranger-Plugin autorisiert hat. Der Geheimagent wird als *`emrsecretagent`*Benutzer ausgeführt und schreibt Protokolle in das Verzeichnis/emr/secretagent/log. Der Prozess benötigt eine bestimmte Zusammenstellung von `iptables`-Regeln, um zu funktionieren. Es ist wichtig sicherzustellen, dass `iptables` nicht deaktiviert ist. Wenn Sie die `iptables`-Konfiguration anpassen, müssen die NAT-Tabellenregeln beibehalten und unverändert bleiben.
**EMR Datensatzserver** – Der Datensatzserver empfängt Anforderungen für den Zugriff auf Daten von Spark. Anschließend autorisiert es Anfragen, indem es die angeforderten Ressourcen an das Spark-Ranger-Plugin für Amazon EMR weiterleitet. Der Datensatzserver liest Daten von Amazon S3 und gibt gefilterte Daten zurück, auf die der Benutzer gemäß der Ranger-Richtlinie zugreifen darf. Der Record-Server läuft auf jedem Knoten im Cluster als Benutzer emr\$1record\$1server und schreibt Protokolle in das Verzeichnis/-record-server. var/log/emr
# Überlegungen zur Verwendung von Amazon EMR mit Apache Ranger
## Unterstützte Anwendungen für Amazon EMR mit Apache Ranger
Die Integration zwischen Amazon EMR und Apache Ranger, in der EMR Ranger-Plugins installiert, unterstützt derzeit die folgenden Anwendungen:
+ Apache Spark (verfügbar mit EMR 5.32\$1 und EMR 6.3\$1)
+ Apache Spark (verfügbar mit EMR 5.32\$1 und EMR 6.3\$1)
+ S3-Zugriff über EMRFS (verfügbar mit EMR 5.32\$1 und EMR 6.3\$1)
Sie können auch die folgenden Anwendungen auf einem EMR-Cluster installieren und sie so konfigurieren, dass sie Ihren Sicherheitsanforderungen entsprechen:
+ Apache Hadoop (verfügbar mit EMR 5.32\$1 und EMR 6.3\$1 einschließlich YARN und HDFS)
+ Apache Livy (verfügbar mit EMR 5.32\$1 und EMR 6.3\$1)
+ Apache Zeppelin (verfügbar mit EMR 5.32\$1 und EMR 6.3\$1)
+ Apache Hue (verfügbar mit EMR 5.32\$1 und EMR 6.3\$1)
+ Ganglia (verfügbar mit EMR 5.32\$1 und EMR 6.3\$1)
+ HCatalog (Verfügbar mit EMR 5.32\$1 und EMR 6.3\$1)
+ Mahout (verfügbar mit EMR 5.32\$1 und EMR 6.3\$1)
+ MXNet (Verfügbar mit EMR 5.32\$1 und EMR 6.3\$1)
+ TensorFlow (Verfügbar mit EMR 5.32\$1 und EMR 6.3\$1)
+ Tez (Verfügbar mit EMR 5.32\$1 und EMR 6.3\$1)
+ Trino (Verfügbar mit EMR 6.7\$1)
+ ZooKeeper (Verfügbar mit EMR 5.32\$1 und EMR 6.3\$1)
**Wichtig**
Die oben aufgeführten Anwendungen sind die einzigen Anwendungen, die derzeit unterstützt werden. Um die Clustersicherheit zu gewährleisten, dürfen Sie einen EMR-Cluster nur mit den Anwendungen in der obigen Liste erstellen, wenn Apache Ranger aktiviert ist.
Andere Anwendungen werden derzeit nicht unterstützt. Um die Sicherheit Ihres Clusters zu gewährleisten, führt der Versuch, andere Anwendungen zu installieren, zur Ablehnung Ihres Clusters.
AWS Glue Data Catalog und Open Table Formate wie Apache Hudi, Delta Lake und Apache Iceberg werden nicht unterstützt.
**Unterstützte Amazon EMR-Funktionen mit Apache Ranger**
Die folgenden Amazon EMR-Funktionen werden unterstützt, wenn Sie Amazon EMR mit Apache Ranger verwenden:
+ Verschlüsselung bei Speicherung und Übertragung
+ Kerberos-Authentifizierung (erforderlich)
+ Instance-Gruppen, Instance-Flotten und Spot Instances
+ Neukonfiguration von Anwendungen auf einem laufenden Cluster
+ Serverseitige Verschlüsselung (SSE) von EMRFS
**Anmerkung**
Die Amazon-EMR-Verschlüsselungseinstellungen regeln SSE. Weitere Informationen finden Sie unter [Verschlüsselungsoptionen](emr-data-encryption-options.md).
## Einschränkungen der Anwendung
Bei der Integration von Amazon EMR und Apache Ranger sind mehrere Einschränkungen zu beachten:
+ Sie können die Konsole derzeit nicht verwenden, um eine Sicherheitskonfiguration zu erstellen, die die AWS Ranger-Integrationsoption in der spezifiziert. AWS GovCloud (US) Region Die Sicherheitskonfiguration kann mit der CLI durchgeführt werden.
+ Kerberos muss in Ihrem Cluster installiert sein.
+ Anwendungen UIs (Benutzeroberflächen) wie die YARN Resource Manager-Benutzeroberfläche, die NameNode HDFS-Benutzeroberfläche und die Livy-Benutzeroberfläche sind standardmäßig nicht mit Authentifizierung ausgestattet.
+ Die HDFS-Standardberechtigungen `umask` sind so konfiguriert, dass erstellte Objekte standardmäßig auf `world wide readable` eingestellt sind.
+ Amazon EMR unterstützt den Hochverfügbarkeitsmodus (mehrere Primärtypen) mit Apache Ranger nicht.
+ Weitere Einschränkungen finden Sie unter Einschränkungen für jede Anwendung.
**Anmerkung**
Die Amazon-EMR-Verschlüsselungseinstellungen regeln SSE. Weitere Informationen finden Sie unter [Verschlüsselungsoptionen](emr-data-encryption-options.md).
## Einschränkungen des Plugins
Jedes Plugin hat spezifische Einschränkungen. Die Einschränkungen des Apache-Hive-Plugins finden Sie unter [Einschränkungen des Apache-Hive-Plugins](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-ranger-hive.html#emr-ranger-hive-limitations). Die Einschränkungen des Apache- Spark-Plugins finden Sie unter [Einschränkungen des Apache-Spark-Plugins](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-ranger-spark.html#emr-ranger-spark-limitations). Die Einschränkungen des EMRFS-S3-Plugins finden Sie unter [Einschränkungen des EMRFS-S3-Plugins](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-ranger-emrfs.html#emr-ranger-emrfs-limitations).
# Amazon EMR für Apache Ranger einrichten
Bevor Sie Apache Ranger installieren, überprüfen Sie die Informationen in diesem Abschnitt, um sicherzustellen, dass Amazon EMR ordnungsgemäß konfiguriert ist.
**Topics**
+ [Richten Sie einen Ranger Admin-Server für die Integration mit Amazon EMR ein](emr-ranger-admin.md)
+ [IAM-Rollen für die native Integration mit Apache Ranger](emr-ranger-iam.md)
+ [Erstellen einer EMR-Sicherheitskonfiguration](emr-ranger-security-config.md)
+ [Speichern Sie TLS-Zertifikate in AWS Secrets Manager](emr-ranger-tls-certificates.md)
+ [Starten Sie einen EMR-Cluster mit Apache Ranger](emr-ranger-start-emr-cluster.md)
+ [Zeppelin für Apache-Ranger-fähige Amazon-EMR-Cluster konfigurieren](emr-ranger-configure-zeppelin.md)
+ [Bekannte Probleme bei der Amazon EMR-Integration](emr-ranger-security-considerations.md)
# Richten Sie einen Ranger Admin-Server für die Integration mit Amazon EMR ein
Für die Amazon-EMR-Integration müssen die Apache-Ranger-Anwendungs-Plugins über TLS/SSL mit dem Admin-Server kommunizieren.
**Voraussetzung: SSL-Aktivierung des Ranger-Admin-Servers**
Apache Ranger auf Amazon EMR erfordert bidirektionale SSL-Kommunikation zwischen Plugins und dem Ranger-Admin-Server. Um sicherzustellen, dass Plugins über SSL mit dem Apache Ranger-Server kommunizieren, aktivieren Sie das folgende Attribut in ranger-admin-site .xml auf dem Ranger Admin-Server.
```
ranger.service.https.attrib.ssl.enabled
true
```
Darüber hinaus sind die folgenden Konfigurationen erforderlich.
```
ranger.https.attrib.keystore.file
__
ranger.service.https.attrib.keystore.file
__
ranger.service.https.attrib.keystore.pass
__
ranger.service.https.attrib.keystore.keyalias
ranger.service.https.attrib.clientAuth
want
ranger.service.https.port
6182
```
# TLS-Zertifikate für die Apache Ranger-Integration mit Amazon EMR
Die Apache-Ranger-Integration mit Amazon EMR erfordert, dass der Datenverkehr von Amazon-EMR-Knoten zum Ranger-Admin-Server mit TLS verschlüsselt wird und dass Ranger-Plugins sich beim Apache-Ranger-Server mithilfe der wechselseitigen TLS-Authentifizierung authentifizieren. Der Amazon-EMR-Service benötigt das öffentliche Zertifikat Ihres Ranger- Admin-Servers (wie im vorherigen Beispiel angegeben) und das private Zertifikat.
**Zertifikate für das Apache-Ranger-Plugin**
Öffentliche TLS-Zertifikate für das Apache Ranger-Plugin müssen für den Apache-Ranger-Admin-Server zugänglich sein, um zu überprüfen, wann die Plugins eine Verbindung herstellen. Es gibt drei verschiedene Methoden, dies zu tun.
**Methode 1: Konfigurieren Sie einen Truststore auf dem Apache-Ranger-Admin-Server**
Füllen Sie die folgenden Konfigurationen in ranger-admin-site .xml aus, um einen Truststore zu konfigurieren.
```
ranger.truststore.file
ranger.truststore.password
```
**Methode 2: Laden Sie das Zertifikat in den Truststore von Java cacerts**
Wenn Ihr Ranger- Admin-Server in seinen JVM-Optionen keinen Truststore angibt, können Sie die öffentlichen Plugin-Zertifikate im Standard-Cacerts-Speicher ablegen.
**Methode 3: Erstellen Sie einen Truststore und geben Sie ihn als Teil der JVM-Optionen an**
Ändern Sie die `{RANGER_HOME_DIRECTORY}/ews/ranger-admin-services.sh` innerhalb von `JAVA_OPTS`, dass sie `"-Djavax.net.ssl.trustStore="` und `"-Djavax.net.ssl.trustStorePassword="` einschließt. Fügen Sie beispielsweise die folgende Zeile nach dem vorhandenen JAVA\$1OPTS hinzu.
```
JAVA_OPTS=" ${JAVA_OPTS} -Djavax.net.ssl.trustStore=${RANGER_HOME}/truststore/truststore.jck -Djavax.net.ssl.trustStorePassword=changeit"
```
**Anmerkung**
Diese Spezifikation kann das Truststore-Passwort offenlegen, wenn sich ein Benutzer beim Apache- Ranger Admin-Server anmelden und laufende Prozesse sehen kann, z. B. wenn er den `ps`-Befehl verwendet.
**Verwenden selbstsignierter Zertifikate**
Selbstsignierte Zertifikate werden als Zertifikate nicht empfohlen. Selbstsignierte Zertifikate können nicht gesperrt werden, und selbstsignierte Zertifikate entsprechen möglicherweise nicht den internen Sicherheitsanforderungen.
# Installation der Servicedefinition für die Ranger-Integration mit Amazon EMR
Eine Servicedefinition wird vom Ranger-Admin-Server verwendet, um die Attribute von Richtlinien für eine Anwendung zu beschreiben. Die Richtlinien werden dann in einem Richtlinien-Repository gespeichert, sodass die Clients sie herunterladen können.
Um Servicedefinitionen konfigurieren zu können, müssen REST-Aufrufe an den Ranger-Admin-Server getätigt werden. Informationen zu den [Anforderungen finden Sie im folgenden Abschnitt unter Apache Ranger Public APIsv2](https://ranger.apache.org/apidocs/resource_PublicAPIsv2.html#resource_PublicAPIsv2_createServiceDef_POST). APIs
**Installation der Servicedefinition von Apache Spark**
Informationen zur Installation der Servicedefinition von Apache Spark finden Sie unter [Apache Spark-Plugin für die Ranger-Integration mit Amazon EMR](emr-ranger-spark.md).
**Installation der EMRFS-Servicedefinition**
Informationen zur Installation der S3-Servicedefinition für Amazon EMR finden Sie unter [EMRFS S3-Plugin für die Ranger-Integration mit Amazon EMR](emr-ranger-emrfs.md).
**Verwenden der Hive-Servicedefinition**
Apache Hive kann die bestehende Ranger-Servicedefinition verwenden, die im Lieferumfang von Apache Ranger 2.0 und höher enthalten ist. Weitere Informationen finden Sie unter [Apache Hive-Plugin für die Ranger-Integration mit Amazon EMR](emr-ranger-hive.md).
# Regeln für den Netzwerkverkehr für die Integration mit Amazon EMR
Wenn Apache Ranger in Ihren EMR-Cluster integriert ist, muss der Cluster mit zusätzlichen Servern und AWS kommunizieren.
Alle Amazon-EMR-Knoten, einschließlich Core- und Aufgabenknoten, müssen in der Lage sein, mit den Apache-Ranger-Admin-Servern zu kommunizieren, um Richtlinien herunterzuladen. Wenn Ihr Apache-Ranger-Admin auf Amazon EC2 läuft, müssen Sie die Sicherheitsgruppe aktualisieren, um Datenverkehr vom EMR-Cluster entgegennehmen zu können.
Zusätzlich zur Kommunikation mit dem Ranger Admin-Server müssen alle Knoten in der Lage sein, mit den folgenden AWS Diensten zu kommunizieren:
+ Amazon S3
+ AWS KMS (bei Verwendung von EMRFS SSE-KMS)
+ Amazon CloudWatch
+ AWS STS
Wenn Sie planen, Ihren EMR-Cluster in einem privaten Subnetz auszuführen, konfigurieren Sie die VPC so, dass sie mit diesen Services entweder über [AWS PrivateLink und VPC-Endpunkte](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html) im *Amazon-VPC-Benutzerhandbuch* oder mithilfe der [Network Address Translation (NAT)-Instance](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html) im *Amazon-VPC-Benutzerhandbuch* kommunizieren kann.
# IAM-Rollen für die native Integration mit Apache Ranger
Die Integration zwischen Amazon EMR und Apache Ranger basiert auf drei Schlüsselrollen, die Sie erstellen sollten, bevor Sie Ihren Cluster starten:
+ Ein benutzerdefiniertes Amazon-EC2-Instance-Profil für Amazon EMR
+ Eine IAM-Rolle für Apache Ranger Engines
+ Eine IAM-Rolle für andere Dienste AWS
Dieser Abschnitt bietet eine Übersicht über diese Rollen und die Richtlinien, die Sie für jede dieser IAM-Rollen einschließen müssen. Informationen zum Erstellen dieser Rollen finden Sie unter [Richten Sie einen Ranger Admin-Server für die Integration mit Amazon EMR ein](emr-ranger-admin.md).
# EC2-Instanzprofil für Amazon EMR
Amazon EMR verwendet eine IAM-Servicerolle, um in Ihrem Namen Aktionen zur Bereitstellung und Verwaltung von Clustern durchzuführen. Die Servicerolle für EC2-Instance-Cluster (auch als EC2-Instance-Profil für Amazon EMR bezeichnet) ist eine spezielle Art von Servicerolle, die jeder EC2-Instance in einem Amazon-EMR-Cluster zugewiesen wird, wenn die Instance startet.
Um Berechtigungen für die EMR-Cluster-Interaktion mit Amazon S3 S3-Daten und mit dem durch Apache Ranger und andere AWS Dienste geschützten Hive-Metastore zu definieren, definieren Sie ein benutzerdefiniertes EC2-Instance-Profil, das anstelle des `EMR_EC2_DefaultRole` beim Starten Ihres Clusters verwendet werden soll.
Weitere Informationen erhalten Sie unter [Servicerolle für EC2-Cluster-Instances (EC2-Instance-Profil)](emr-iam-role-for-ec2.md) und [Passen Sie IAM-Rollen mit Amazon EMR an](emr-iam-roles-custom.md).
Sie müssen die folgenden Anweisungen zum standardmäßigen EC2-Instance-Profil für Amazon EMR hinzufügen, um Sitzungen taggen und auf die zugreifen zu können, in AWS Secrets Manager denen TLS-Zertifikate gespeichert sind.
```
{
"Sid": "AllowAssumeOfRolesAndTagging",
"Effect": "Allow",
"Action": ["sts:TagSession", "sts:AssumeRole"],
"Resource": [
"arn:aws:iam:::role/",
"arn:aws:iam:::role/"
]
},
{
"Sid": "AllowSecretsRetrieval",
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": [
"arn:aws:secretsmanager:::secret:*",
"arn:aws:secretsmanager:::secret:*"
]
}
```
**Anmerkung**
Vergessen Sie bei den Secrets- Manager-Berechtigungen nicht den Platzhalter („\$1“) am Ende des geheimen Namens, da Ihre Anfragen sonst fehlschlagen. Der Platzhalter gilt für geheime Versionen.
**Anmerkung**
Beschränken Sie den Geltungsbereich der AWS Secrets Manager Richtlinie auf die Zertifikate, die für die Bereitstellung erforderlich sind.
# IAM-Rolle für Apache Ranger
Diese Rolle stellt Anmeldeinformationen für vertrauenswürdige Ausführungs-Engines wie Apache Hive und Amazon EMR Record Server bereit, um auf Amazon-S3-Daten zuzugreifen. Verwenden Sie nur diese Rolle, um auf Amazon-S3-Daten, einschließlich aller KMS-Schlüssel, zuzugreifen, wenn Sie S3 SSE-KMS verwenden.
Diese Rolle muss mit der im folgenden Beispiel angegebenen Mindestrichtlinie erstellt werden.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "CloudwatchLogsPermissions",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Effect": "Allow",
"Resource": [
"arn:aws:logs:*:123456789012:log-group:CLOUDWATCH_LOG_GROUP_NAME_IN_SECURITY_CONFIGURATION:*"
]
},
{
"Sid": "BucketPermissionsInS3Buckets",
"Action": [
"s3:CreateBucket",
"s3:DeleteBucket",
"s3:ListAllMyBuckets",
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket1",
"arn:aws:s3:::amzn-s3-demo-bucket2"
]
},
{
"Sid": "ObjectPermissionsInS3Objects",
"Action": [
"s3:GetObject",
"s3:DeleteObject",
"s3:PutObject"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket1/*",
"arn:aws:s3:::amzn-s3-demo-bucket2/*"
]
}
]
}
```
------
**Wichtig**
Das Sternchen „\$1“ am Ende der CloudWatch Protokollressource muss enthalten sein, um Schreibberechtigungen für die Protokolldatenströme zu erteilen.
**Anmerkung**
Wenn Sie die EMRFS-Konsistenzansicht oder die S3-SSE-Verschlüsselung verwenden, fügen Sie den DynamoDB-Tabellen und KMS-Schlüsseln Berechtigungen hinzu, damit die Ausführungsmodule mit diesen Engines interagieren können.
Die IAM-Rolle für Apache Ranger wird von der EC2-Instance-Profilrolle übernommen. Verwenden Sie das folgende Beispiel, um eine Vertrauensrichtlinie zu erstellen, die es ermöglicht, dass die IAM-Rolle für Apache Ranger von der EC2-Instance-Profilrolle übernommen wird.
```
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam:::role/"
},
"Action": ["sts:AssumeRole", "sts:TagSession"]
}
```
# IAM-Rolle für andere AWS Services für die Amazon EMR-Integration
Diese Rolle stellt Benutzern, denen Execution Engines nicht vertraut werden, bei Bedarf Anmeldeinformationen für die Interaktion mit AWS Diensten zur Verfügung. Verwenden Sie diese IAM-Rolle nicht, um Zugriff auf Amazon-S3-Daten zu gewähren, es sei denn, es handelt sich um Daten, auf die alle Benutzer zugreifen können sollten.
Diese Rolle wird von der EC2-Instance-Profilrolle übernommen. Verwenden Sie das folgende Beispiel, um eine Vertrauensrichtlinie zu erstellen, die es ermöglicht, dass die IAM-Rolle für Apache Ranger von der EC2-Instance-Profilrolle übernommen wird.
```
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam:::role/"
},
"Action": ["sts:AssumeRole", "sts:TagSession"]
}
```
# Überprüfen Sie Ihre Berechtigungen für die Amazon EMR-Integration mit Apache Ranger
Anweisungen zum Überprüfen von Berechtigungen finden Sie unter [Fehlerbehebung für Apache Ranger](emr-ranger-troubleshooting.md).
# Erstellen einer EMR-Sicherheitskonfiguration
**Eine Amazon-EMR-Sicherheitskonfiguration für Apache Ranger erstellen**
Bevor Sie einen in Apache Ranger integrierten Amazon-EMR-Cluster starten, erstellen Sie eine Sicherheitskonfiguration.
------
#### [ Console ]
**Um eine Sicherheitskonfiguration zu erstellen, die die AWS Ranger-Integrationsoption spezifiziert**
1. Wählen Sie in der Amazon-EMR-Konsole die Optionen **Sicherheitskonfigurationen** und dann **Erstellen** aus.
1. Geben Sie in **Name (Name)** einen Namen für die Sicherheitskonfiguration ein. Verwenden Sie diesen Namen zum Angeben der Sicherheitskonfiguration, wenn Sie einen Cluster erstellen.
1. Wählen Sie unter **AWS -Ranger-Integration** die Option **Aktivieren einer von Apache Ranger verwalteten feinkörnigen Zugriffskontrolle**.
1. Wählen Sie Ihre **IAM-Rolle für die Apache Ranger**, die angewendet werden soll. Weitere Informationen finden Sie unter [IAM-Rollen für die native Integration mit Apache Ranger](emr-ranger-iam.md).
1. Wählen Sie eine **IAM-Rolle für andere AWS -Services** aus, die angewendet werden soll.
1. Konfigurieren Sie die Plugins so, dass sie eine Verbindung zum Ranger Admin-Server herstellen, indem Sie den Secrets Manager Manager-ARN für den Admin-Server und die Adresse eingeben.
1. Wählen Sie die Anwendungen aus, um Ranger-Plugins zu konfigurieren. Geben Sie den Secrets Manager ARN ein, der das private TLS-Zertifikat für das Plugin enthält.
Wenn Sie Apache Spark oder Apache Hive nicht konfigurieren und diese als Anwendung für Ihren Cluster ausgewählt wurden, schlägt die Anfrage fehl.
1. Richten Sie weitere Sicherheitskonfigurationsoptionen ein wie erforderlich. Wählen Sie **Create (Erstellen)** aus. Sie müssen die Kerberos-Authentifizierung mit dem Cluster-spezifischen oder externen KDC aktivieren.
**Anmerkung**
Sie können die Konsole derzeit nicht verwenden, um eine Sicherheitskonfiguration zu erstellen, die die AWS Ranger-Integrationsoption in der AWS GovCloud (US) Region spezifiziert. Die Sicherheitskonfiguration kann mit der CLI durchgeführt werden.
------
#### [ CLI ]
**Wie Sie eine Sicherheitskonfiguration für die Apache Ranger-Integration erstellen**
1. Ersetzen Sie es `` durch Ihre AWS Konto-ID.
1. Ersetzen Sie `` durch die Region, in der sich die Ressource befindet.
1. Geben Sie einen Wert für `TicketLifetimeInHours` an, um den Zeitraum zu anzugeben, für den ein vom KDC ausgestelltes Kerberos-Ticket gültig ist.
1. Geben Sie die Adresse des Ranger-Admin-Servers für `AdminServerURL` an.
```
{
"AuthenticationConfiguration": {
"KerberosConfiguration": {
"Provider": "ClusterDedicatedKdc",
"ClusterDedicatedKdcConfiguration": {
"TicketLifetimeInHours": 24
}
}
},
"AuthorizationConfiguration":{
"RangerConfiguration":{
"AdminServerURL":"https://__:6182",
"RoleForRangerPluginsARN":"arn:aws:iam::__:role/__",
"RoleForOtherAWSServicesARN":"arn:aws:iam::__:role/__",
"AdminServerSecretARN":"arn:aws:secretsmanager:__:__:secret:__",
"RangerPluginConfigurations":[
{
"App":"Spark",
"ClientSecretARN":"arn:aws:secretsmanager:__:__:secret:__",
"PolicyRepositoryName":""
},
{
"App":"Hive",
"ClientSecretARN":"arn:aws:secretsmanager:__:__:secret:__",
"PolicyRepositoryName":""
},
{
"App":"EMRFS-S3",
"ClientSecretARN":"arn:aws:secretsmanager:__:__:secret:__",
"PolicyRepositoryName":""
},
{
"App":"Trino",
"ClientSecretARN":"arn:aws:secretsmanager:__:__:secret:__",
"PolicyRepositoryName":""
}
],
"AuditConfiguration":{
"Destinations":{
"AmazonCloudWatchLogs":{
"CloudWatchLogGroup":"arn:aws:logs::__:log-group:__"
}
}
}
}
}
}
```
Dies PolicyRespositoryNames sind die Dienstnamen, die in Ihrem Apache Ranger Admin angegeben sind.
Erstellen Sie eine Amazon-EMR-Datei für die Sicherheitskonfiguration mit dem folgenden Befehl. Ersetzen Sie Sicherheitskonfiguration durch einen beliebigen Namen. Wählen Sie diese Konfiguration beim Erstellen Ihres Clusters nach Namen aus.
```
aws emr create-security-configuration \
--security-configuration file://./security-configuration.json \
--name security-configuration
```
------
**Konfigurieren von zusätzlichen Sicherheits-Features**
Um sicherzustellen, dass Amazon EMR sicher in Apache Ranger integriert ist, konfigurieren Sie die folgenden EMR-Sicherheits-Features:
+ Aktivieren Sie die Kerberos-Authentifizierung über den Cluster-spezifischen oder externen KDC. Detaillierte Anweisungen finden Sie unter [Verwenden Sie Kerberos für die Authentifizierung mit Amazon EMR](emr-kerberos.md).
+ (Optional) Aktivieren Sie die Verschlüsselung von Daten während der Übertragung oder im Ruhezustand. Weitere Informationen finden Sie unter [Verschlüsselungsoptionen für Amazon EMR](emr-data-encryption-options.md).
Weitere Informationen finden Sie unter [Sicherheit in Amazon EMR](emr-security.md).
# Speichern Sie TLS-Zertifikate in AWS Secrets Manager
Die auf einem Amazon-EMR-Cluster installierten Ranger-Plugins und der Ranger- Admin-Server müssen über TLS kommunizieren, um sicherzustellen, dass Richtliniendaten und andere gesendete Informationen nicht gelesen werden können, wenn sie abgefangen werden. EMR schreibt außerdem vor, dass sich die Plugins beim Ranger-Admin-Server authentifizieren, indem sie ein eigenes TLS-Zertifikat bereitstellen und eine bidirektionale TLS-Authentifizierung durchführen. Für dieses Setup mussten vier Zertifikate erstellt werden: zwei Paare von privaten und öffentlichen TLS-Zertifikaten. Anweisungen zur Installation des Zertifikats auf Ihrem Ranger Admin-Server finden Sie unter [Richten Sie einen Ranger Admin-Server für die Integration mit Amazon EMR ein](emr-ranger-admin.md). Um die Einrichtung abzuschließen, benötigen die auf dem EMR-Cluster installierten Ranger-Plugins zwei Zertifikate: das öffentliche TLS-Zertifikat Ihres Admin-Servers und das private Zertifikat, das das Plugin zur Authentifizierung gegenüber dem Ranger-Admin-Server verwendet. Um diese TLS-Zertifikate bereitstellen zu können, müssen sie sich in der EMR-Sicherheitskonfiguration befinden AWS Secrets Manager und in dieser bereitgestellt werden.
**Anmerkung**
Es wird dringend empfohlen, aber nicht vorgeschrieben, für jede Ihrer Anwendungen ein Zertifikatspaar zu erstellen, um die Auswirkungen zu begrenzen, falls eines der Plugin-Zertifikate kompromittiert wird.
**Anmerkung**
Sie müssen Zertifikate vor ihrem Ablaufdatum nachverfolgen und rotieren.
## Zertifikatformat
Das Importieren der Zertifikate in das AWS Secrets Manager ist identisch, unabhängig davon, ob es sich um das private Plugin-Zertifikat oder das öffentliche Ranger-Administratorzertifikat handelt. Vor dem Import der TLS-Zertifikate müssen die Zertifikate im 509x PEM-Format vorliegen.
Ein Beispiel für ein öffentliches Zertifikat hat das folgende Format:
```
-----BEGIN CERTIFICATE-----
...Certificate Body...
-----END CERTIFICATE-----
```
Ein Beispiel für ein privates Zertifikat hat das folgende Format:
```
-----BEGIN PRIVATE KEY-----
...Private Certificate Body...
-----END PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
...Trust Certificate Body...
-----END CERTIFICATE-----
```
Das private Zertifikat sollte auch ein Vertrauenszertifikat enthalten.
Mit folgendem Befehl können Sie prüfen, ob die Zertifikate das richtige Format haben:
```
openssl x509 -in -text
```
## Importieren eines Zertifikats in das AWS Secrets Manager
Wenn Sie Ihr Geheimnis im Secrets Manager erstellen, wählen Sie **Andere Art von Geheimnissen** unter **Geheimnistyp** und fügen Sie Ihr PEM-codiertes Zertifikat in das **Klartext-Feld** ein.
![\[Ein Zertifikat importieren in AWS Secrets Manager.\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/images/ranger-tls-cert-import.png)
# Starten Sie einen EMR-Cluster mit Apache Ranger
Bevor Sie einen Amazon-EMR-Cluster mit Apache Ranger starten, stellen Sie sicher, dass jede Komponente die folgenden Mindestanforderungen an die Version erfüllt:
+ Amazon EMR 5.32.0 oder höher oder 6.3.0 oder höher. Es wird empfohlen, die neueste Amazon-EMR-Release-Version zu verwenden.
+ Apache Ranger Admin-Server 2.x.
Führen Sie folgende Schritte aus.
+ Installieren Sie Apache Ranger, wenn das noch nicht geschehen ist. Weitere Informationen finden Sie unter [Installation von Apache Ranger 0.5.0](https://cwiki.apache.org/confluence/display/RANGER/Apache+Ranger+0.5.0+Installation).
+ Stellen Sie sicher, dass zwischen Ihrem Amazon-EMR-Cluster und dem Apache-Ranger-Admin-Server eine Netzwerkverbindung besteht. Siehe [Richten Sie einen Ranger Admin-Server für die Integration mit Amazon EMR ein](emr-ranger-admin.md)
+ Erstellen Sie die erforderlichen IAM-Rollen. Siehe [IAM-Rollen für die native Integration mit Apache Ranger](emr-ranger-iam.md).
+ Erstellen Sie eine EMR-Sicherheitskonfiguration für die Apache-Ranger-Installation. Weitere Informationen finden Sie unter [Erstellen einer EMR-Sicherheitskonfiguration](emr-ranger-security-config.md).
# Zeppelin für Apache-Ranger-fähige Amazon-EMR-Cluster konfigurieren
Das Thema behandelt die Konfiguration von [Apache Zeppelin](https://zeppelin.apache.org/) für einen Apache-Ranger-fähigen Amazon-EMR-Cluster, sodass Sie Zeppelin als Notizbuch für die interaktive Datenexploration verwenden können. Zeppelin ist in Amazon-EMR-Versionen 5.0.0 und höher enthalten. Frühere Versionen enthalten Zeppelin als Sandbox-Anwendung. Weitere Informationen finden Sie unter [Informationen zu Amazon-EMR–4.x-Versionen](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-release-4x.html) in den *Amazon-EMR-Versionshinweisen*.
Standardmäßig ist Zeppelin mit einem Standard-Login und Passwort konfiguriert, was in einer Umgebung mit mehreren Mandanten nicht sicher ist.
Führen Sie für die Konfiguration von Zeppelin die folgenden Schritte aus.
1. **Verändern Sie den Authentifizierungsmechanismus**.
Ändern Sie die `shiro.ini`-Datei, um Ihren bevorzugten Authentifizierungsmechanismus zu implementieren. Zeppelin unterstützt Active Directory, LDAP, PAM und Knox SSO. Weitere Informationen finden Sie unter [Apache-Shiro-Authentifizierung für Apache Zeppelin](https://zeppelin.apache.org/docs/0.8.2/setup/security/shiro_authentication.html).
1. **Konfigurieren Sie Zeppelin so, dass es sich als Endbenutzer ausgibt**
Wenn Sie Zeppelin erlauben, sich als Endbenutzer auszugeben, können von Zeppelin eingereichte Aufträge als dieser Endbenutzer ausgeführt werden. Fügen Sie die folgende Konfiguration zu `core-site.xml` hinzu:
```
[
{
"Classification": "core-site",
"Properties": {
"hadoop.proxyuser.zeppelin.hosts": "*",
"hadoop.proxyuser.zeppelin.groups": "*"
},
"Configurations": [
]
}
]
```
Fügen Sie als Nächstes die folgende Konfiguration zu `hadoop-kms-site.xml` in `/etc/hadoop/conf` hinzu:
```
[
{
"Classification": "hadoop-kms-site",
"Properties": {
"hadoop.kms.proxyuser.zeppelin.hosts": "*",
"hadoop.kms.proxyuser.zeppelin.groups": "*"
},
"Configurations": [
]
}
]
```
Sie können diese Konfigurationen auch mithilfe der Konsole zu Ihrem Amazon-EMR-Cluster hinzufügen, indem Sie die Schritte unter [Instance-Gruppe in der Konsole neu konfigurieren](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps-running-cluster.html#emr-configure-apps-running-cluster-console) befolgen.
1. **Erlauben Sie Zeppelin, als Endbenutzer sudo auszuführen**
Erstellen Sie eine Datei `/etc/sudoers.d/90-zeppelin-user`, die folgendes enthält:
```
zeppelin ALL=(ALL) NOPASSWD:ALL
```
1. **Ändern Sie die Einstellungen der Interpreter, um Benutzeraufträge in ihren eigenen Prozessen auszuführen**.
Konfigurieren Sie alle Interpreter so, dass sie die Interpreter „pro Benutzer“ in „isolierten“ Prozessen instanziieren.
![\[Architekturdiagramm von Amazon EMR und Apache Ranger.\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/images/per_user.png)
1. **Modifizieren Sie `zeppelin-env.sh`**
Fügen Sie Folgendes zu `zeppelin-env.sh` hinzu, damit Zeppelin die Interpreter als Endbenutzer startet:
```
ZEPPELIN_IMPERSONATE_USER=`echo ${ZEPPELIN_IMPERSONATE_USER} | cut -d @ -f1`
export ZEPPELIN_IMPERSONATE_CMD='sudo -H -u ${ZEPPELIN_IMPERSONATE_USER} bash -c'
```
Fügen Sie Folgendes zu `zeppelin-env.sh` hinzu, um die standardmäßigen Notebookberechtigungen für den Ersteller auf Schreibgeschützt zu ändern:
```
export ZEPPELIN_NOTEBOOK_PUBLIC="false"
```
Fügen Sie abschließend Folgendes hinzu, `zeppelin-env.sh` um den RecordServer EMR-Klassenpfad nach der ersten `CLASSPATH` Anweisung einzubeziehen:
```
export CLASSPATH="$CLASSPATH:/usr/share/aws/emr/record-server/lib/aws-emr-record-server-connector-common.jar:/usr/share/aws/emr/record-server/lib/aws-emr-record-server-spark-connector.jar:/usr/share/aws/emr/record-server/lib/aws-emr-record-server-client.jar:/usr/share/aws/emr/record-server/lib/aws-emr-record-server-common.jar:/usr/share/aws/emr/record-server/lib/jars/secret-agent-interface.jar"
```
1. **Starten Sie Zeppelin neu.**
Führen Sie für den folgenden Befehle aus, um Zeppelin neu zu starten:
```
sudo systemctl restart zeppelin
```
# Bekannte Probleme bei der Amazon EMR-Integration
**Bekannte Probleme**
Es gibt ein bekanntes Problem in Amazon-EMR-Version 5.32, bei dem die Berechtigungen für `hive-site.xml` geändert wurden, sodass nur privilegierte Benutzer es lesen können, da möglicherweise Anmeldeinformationen darin gespeichert sind. Dies könnte Hue am Lesen von `hive-site.xml` hindern und dazu führen, dass Webseiten ständig neu geladen werden. Wenn dieses Problem auftritt, fügen Sie die folgende Konfiguration hinzu, um das Problem zu beheben:
```
[
{
"Classification": "hue-ini",
"Properties": {},
"Configurations": [
{
"Classification": "desktop",
"Properties": {
"server_group":"hive_site_reader"
},
"Configurations":[
]
}
]
}
]
```
Es gibt ein bekanntes Problem, dass das EMRFS-S3-Plugin für Apache Ranger das Security-Zone-Feature von Apache Ranger derzeit nicht unterstützt. Einschränkungen der Zugriffskontrolle, die mit demr Sicherheitszone-Feature definiert wurden, gelten nicht für Ihre Amazon-EMR-Cluster.
**Anwendung UIs**
Standardmäßig führen Benutzeroberflächen von Anwendungen keine Authentifizierung durch. Dazu gehören unter anderem die ResourceManager Benutzeroberfläche, die NodeManager Benutzeroberfläche und die Livy-Benutzeroberfläche. Darüber hinaus kann jeder Benutzer, der auf die UIs zugreifen kann, Informationen zu den Jobs aller anderen Benutzer einsehen.
Wenn dieses Verhalten nicht erwünscht ist, sollten Sie sicherstellen, dass eine Sicherheitsgruppe verwendet wird, um den Zugriff der Benutzer auf die Anwendung UIs einzuschränken.
**HDFS-Standardberechtigungen**
Standardmäßig erhalten die Objekte, die Benutzer in HDFS erstellen, weltweit lesbare Berechtigungen. Dies kann möglicherweise dazu führen, dass Daten von Benutzern gelesen werden, die keinen Zugriff darauf haben sollten. Gehen Sie wie folgt vor, um dieses Verhalten so zu ändern, dass die standardmäßigen Dateiberechtigungen nur vom Ersteller des Auftrags auf Lese- und Schreibzugriff festgelegt werden.
Geben Sie bei der Erstellung Ihres EMR-Clusters die folgende Konfiguration an:
```
[
{
"Classification": "hdfs-site",
"Properties": {
"dfs.namenode.acls.enabled": "true",
"fs.permissions.umask-mode": "077",
"dfs.permissions.superusergroup": "hdfsadmingroup"
}
}
]
```
Führen Sie außerdem die folgende Bootstrap-Aktion aus:
```
--bootstrap-actions Name='HDFS UMask Setup',Path=s3://elasticmapreduce/hdfs/umask/umask-main.sh
```
# Apache Ranger-Plugins für Amazon EMR-Integrationsszenarien
Apache-Ranger-Plugin – Dieses Plugin validiert den Zugriff eines Benutzers anhand der Autorisierungsrichtlinien, die im Apache-Ranger-Richtlinien-Admin-Server definiert sind.
**Topics**
+ [Apache Hive-Plugin für die Ranger-Integration mit Amazon EMR](emr-ranger-hive.md)
+ [Apache Spark-Plugin für die Ranger-Integration mit Amazon EMR](emr-ranger-spark.md)
+ [EMRFS S3-Plugin für die Ranger-Integration mit Amazon EMR](emr-ranger-emrfs.md)
+ [Trino-Plugin für die Ranger-Integration mit Amazon EMR](emr-ranger-trino.md)
# Apache Hive-Plugin für die Ranger-Integration mit Amazon EMR
Apache Hive ist eine beliebte Ausführungs-Engine innerhalb des Hadoop-Ökosystems. Amazon EMR bietet ein Apache-Ranger-Plugin, um detaillierte Zugriffskontrollen für Hive bereitstellen zu können. Das Plugin ist mit Admin-Server-Version von Open-Source-Apache-Ranger 2.0 und höher kompatibel.
**Topics**
+ [Unterstützte Features](#emr-ranger-supported-features)
+ [Installation der Servicekonfiguration](#emr-ranger-hive-service-config)
+ [Überlegungen](#emr-ranger-hive-considerations)
+ [Einschränkungen](#emr-ranger-hive-limitations)
## Unterstützte Features
Das Apache Ranger-Plugin für Hive on EMR unterstützt alle Funktionen des Open-Source-Plugins, einschließlich Zugriffskontrollen auf Datenbank-, Tabellen- und Spaltenebene sowie Zeilenfilterung und Datenmaskierung. Eine Tabelle mit Hive-Befehlen und den zugehörigen Ranger-Berechtigungen finden Sie unter Zuordnung von [Hive-Befehlen zu Ranger-Berechtigungen](https://cwiki.apache.org/confluence/display/RANGER/Hive+Commands+to+Ranger+Permission+Mapping).
## Installation der Servicekonfiguration
Das Apache Hive-Plug-in ist mit der vorhandenen Hive-Servicedefinition in Apache Hive Hadoop SQL kompatibel.
![\[Apache-Hive-Servicedefinition für Hadoop SQL.\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/images/ranger_service_mgr.png)
Wenn Sie keine Instance des Services unter Hadoop SQL haben, wie oben gezeigt, können Sie eine erstellen. Klicken Sie auf das **\$1** neben Hadoop SQL.
1. **Servicename (falls angezeigt)**: Geben Sie den Servicenamen ein. Der vorgeschlagene Wert ist **amazonemrhive**. Notieren Sie sich diesen Servicenamen – er wird benötigt, wenn Sie eine EMR-Sicherheitskonfiguration erstellen.
1. **Anzeigename**: Der Name, der für diesen Service angezeigt wird. Der vorgeschlagene Wert ist **amazonemrhive**.
![\[Apache-Hive-Servicedetails für Hadoop SQL.\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/images/ranger_create_service.png)
Die Apache Hive Config Properties werden verwendet, um eine Verbindung zu Ihrem Apache Ranger Admin-Server mit einer HiveServer 2 herzustellen, um die auto Vervollständigung bei der Erstellung von Richtlinien zu implementieren. Die folgenden Eigenschaften müssen nicht korrekt sein, wenn Sie nicht über einen persistenten HiveServer 2-Prozess verfügen, und sie können mit beliebigen Informationen gefüllt werden.
+ **Benutzername**: Geben Sie einen Benutzernamen für die JDBC-Verbindung zu einer Instanz einer HiveServer 2-Instanz ein.
+ **Passwort**: Geben Sie das Passwort für den obigen Benutzernamen ein.
+ **jdbc.driver. ClassName**: Geben Sie den Klassennamen der JDBC-Klasse für Apache Hive-Konnektivität ein. Sie können den Standardwert verwenden.
+ **jdbc.url**: Geben Sie die JDBC-Verbindungszeichenfolge ein, die beim Herstellen einer Verbindung zu 2 verwendet werden soll. HiveServer
+ **Allgemeiner Name für das Zertifikat**: Das CN-Feld innerhalb des Zertifikats, das verwendet wird, um von einem Client-Plugin aus eine Verbindung zum Admin-Server herzustellen. Dieser Wert muss mit dem CN-Feld in Ihrem TLS-Zertifikat übereinstimmen, das für das Plugin erstellt wurde.
![\[Konfigurationseigenschaften des Apache-Hive-Services.\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/images/ranger_config_props.png)
Mit der Schaltfläche **Verbindung testen** wird getestet, ob die obigen Werte verwendet werden können, um erfolgreich eine Verbindung mit der 2-Instanz herzustellen. HiveServer Sobald der Service erfolgreich erstellt wurde, sollte der Service Manager wie folgt aussehen:
![\[Mit der HiveServer 2-Instanz verbunden\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/images/ranger_config_connected.png)
## Überlegungen
**Hive-Metadatenserver**
Zum Schutz vor unbefugtem Zugriff können nur vertrauenswürdige Engines, insbesondere Hive und `emr_record_server`, auf den Hive-Metadatenserver zugreifen. Auf den Hive-Metadatenserver greifen auch alle Knoten im Cluster zu. Der erforderliche Port 9 083 ermöglicht allen Knoten den Zugriff auf den Hauptknoten.
**Authentifizierung**
Standardmäßig ist Apache Hive für die Authentifizierung mithilfe von Kerberos konfiguriert, wie in der EMR Security-Konfiguration konfiguriert. HiveServer2 kann so konfiguriert werden, dass Benutzer auch über LDAP authentifiziert werden. Weitere Informationen finden Sie unter [Implementieren der LDAP-Authentifizierung für Hive auf einem Amazon-EMR-Cluster mit mehreren Mandanten](https://aws.amazon.com/blogs/big-data/implementing-ldap-authentication-for-hive-on-a-multi-tenant-amazon-emr-cluster/).
## Einschränkungen
Die folgenden Einschränkungen gelten derzeit für das Apache Hive-Plugin auf Amazon EMR 5.x:
+ Hive-Rollen werden derzeit nicht unterstützt. Die Anweisungen „Grant“ und „Revoke“ werden nicht unterstützt.
+ Hive CLI wird nicht unterstützt. JDBC/Beeline ist der einzig autorisierte Weg, Hive zu verbinden.
+ `hive.server2.builtin.udf.blacklist`Die Konfiguration sollte mit Daten gefüllt sein UDFs , die Sie für unsicher halten.
# Apache Spark-Plugin für die Ranger-Integration mit Amazon EMR
Amazon EMR hat EMR integriert, RecordServer um eine differenzierte Zugriffskontrolle für SparkSQL zu ermöglichen. EMR RecordServer ist ein privilegierter Prozess, der auf allen Knoten eines Apache Ranger-fähigen Clusters ausgeführt wird. Wenn ein Spark-Treiber oder -Executor eine SparkSQL-Anweisung ausführt, durchlaufen alle Metadaten und Datenanforderungen die. RecordServer Weitere Informationen zu EMR RecordServer finden Sie [Amazon EMR-Komponenten zur Verwendung mit Apache Ranger](emr-ranger-components.md) auf der Seite.
**Topics**
+ [Unterstützte Features](#emr-ranger-spark-supported-features)
+ [Stellen Sie die Servicedefinition erneut bereit, um INSERT-, ALTER- oder DDL-Anweisungen zu verwenden](#emr-ranger-spark-redeploy-service-definition)
+ [Installation der Servicedefinition](#emr-ranger-spark-install-servicedef)
+ [Erstellen von SparkSQL-Richtlinien](#emr-ranger-spark-create-sparksql)
+ [Überlegungen](#emr-ranger-spark-considerations)
+ [Einschränkungen](#emr-ranger-spark-limitations)
## Unterstützte Features
| SQL-Aktion statement/Ranger | STATUS | Unterstützte Versionen für Amazon EMR |
| --- | --- | --- |
| SELECT | Unterstützt | Ab 5.32 |
| SHOW DATABASES | Unterstützt | Ab 5.32 |
| SHOW\$1COLUMNS | Unterstützt | Ab 5.32 |
| SHOW TABLES | Unterstützt | Ab 5.32 |
| ANZEIGEN DER TABELLENEINGENSCHAFTEN | Unterstützt | Ab 5.32 |
| DESCRIBE TABLE | Unterstützt | Ab 5.32 |
| INSERT OVERWRITE | Unterstützt | Ab 5.34 und 6.4 |
| INSERT INTO | Unterstützt | Ab 5.34 und 6.4 |
| ALTER TABLE | Unterstützt | Ab 6.4 |
| CREATE TABLE | Unterstützt | Ab 5.35 und 6.7 |
| CREATE DATABASE | Unterstützt | Ab 5.35 und 6.7 |
| DROP TABLE | Unterstützt | Ab 5.35 und 6.7 |
| DROP DATABASE | Unterstützt | Ab 5.35 und 6.7 |
| DROP VIEW | Unterstützt | Ab 5.35 und 6.7 |
| CREATE VIEW | Nicht unterstützt | |
Die folgenden Feature werden bei der Verwendung von SparkSQL unterstützt:
+ Eine detaillierte Zugriffskontrolle für Tabellen im Hive-Metastore und Richtlinien können auf Datenbank-, Tabellen- und Spaltenebene erstellt werden.
+ Die Richtlinien von Apache Ranger können Richtlinien für die Gewährung und die Ablehnung von Benutzern und Gruppen beinhalten.
+ Prüfereignisse werden an CloudWatch Logs übermittelt.
## Stellen Sie die Servicedefinition erneut bereit, um INSERT-, ALTER- oder DDL-Anweisungen zu verwenden
**Anmerkung**
Ab Amazon EMR 6.4 können Sie Spark SQL mit den folgenden Anweisungen verwenden: INSERT INTO, INSERT OVERWRITE oder ALTER TABLE. Ab Amazon EMR 6.7 können Sie Spark SQL verwenden, um Datenbanken und Tabellen zu erstellen oder zu löschen. Wenn Sie bereits über eine Installation auf dem Apache Ranger-Server mit bereitgestellten Apache Spark-Servicedefinitionen verfügen, verwenden Sie den folgenden Code, um die Servicedefinitionen erneut bereitzustellen.
```
# Get existing Spark service definition id calling Ranger REST API and JSON processor
curl --silent -f -u : \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-k 'https://**:6182/service/public/v2/api/servicedef/name/amazon-emr-spark' | jq .id
# Download the latest Service definition
wget https://s3.amazonaws.com/elasticmapreduce/ranger/service-definitions/version-2.0/ranger-servicedef-amazon-emr-spark.json
# Update the service definition using the Ranger REST API
curl -u : -X PUT -d @ranger-servicedef-amazon-emr-spark.json \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-k 'https://**:6182/service/public/v2/api/servicedef/'
```
## Installation der Servicedefinition
Die Installation der Trino-Servicedefinition erfordert die Einrichtung des Ranger-Admin-Servers. Siehe [Richten Sie einen Ranger Admin-Server für die Integration mit Amazon EMR ein](emr-ranger-admin.md).
Gehen Sie wie folgt vor, um die Apache-Spark-Servicedefinition zu installieren:
**Schritt 1: SSH-Verbindung zum Apache-Ranger-Admin-Server herstellen**
Beispiel:
```
ssh ec2-user@ip-xxx-xxx-xxx-xxx.ec2.internal
```
**Schritt 2: Die Servicedefinition und das Apache-Ranger-Admin-Server-Plugin herunterladen**
Laden Sie die Servicedefinition in einem temporären Verzeichnis herunter. Diese Servicedefinition wird von Ranger-2.x-Versionen unterstützt.
```
mkdir /tmp/emr-spark-plugin/
cd /tmp/emr-spark-plugin/
wget https://s3.amazonaws.com/elasticmapreduce/ranger/service-definitions/version-2.0/ranger-spark-plugin-2.x.jar
wget https://s3.amazonaws.com/elasticmapreduce/ranger/service-definitions/version-2.0/ranger-servicedef-amazon-emr-spark.json
```
**Schritt 3: Das Apache-Spark-Plugin für Amazon EMR installieren**
```
export RANGER_HOME=.. # Replace this Ranger Admin's home directory eg /usr/lib/ranger/ranger-2.0.0-admin
mkdir $RANGER_HOME/ews/webapp/WEB-INF/classes/ranger-plugins/amazon-emr-spark
mv ranger-spark-plugin-2.x.jar $RANGER_HOME/ews/webapp/WEB-INF/classes/ranger-plugins/amazon-emr-spark
```
**Schritt 4: Die Apache-Spark-Servicedefinition für Amazon EMR registrieren**
```
curl -u **:*_<_**_password_ **_for_** _ranger admin user_**_>_* -X POST -d @ranger-servicedef-amazon-emr-spark.json \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-k 'https://**:6182/service/public/v2/api/servicedef'
```
Wenn dieser Befehl erfolgreich ausgeführt wird, sehen Sie in der Ranger-Admin-Benutzeroberfläche einen neuen Servicenamens „AMAZON-EMR-SPARK", wie im folgenden Image gezeigt (Ranger-Version 2.0 wird angezeigt).
![\[„AMAZON-EMR-SPARK“ ist in Ranger-Admin registriert.\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/images/ranger-amazon-emr-spark.png)
**Schritt 5: Erstellen Sie eine Instanz der AMAZON-EMR-SPARK Anwendung**
**Servicename (falls angezeigt):** Der Servicename, der verwendet wird. Der vorgeschlagene Wert ist **amazonemrspark**. Notieren Sie sich diesen Servicenamen, da er für die Erstellung einer EMR-Sicherheitskonfiguration benötigt wird.
**Anzeigename:** Der Name, der für diese Instance angezeigt werden soll. Der vorgeschlagene Wert ist **amazonemrspark**.
**Allgemeiner Name für das Zertifikat**: Das CN-Feld innerhalb des Zertifikats, das verwendet wird, um von einem Client-Plugin aus eine Verbindung zum Admin-Server herzustellen. Dieser Wert muss mit dem CN-Feld in Ihrem TLS-Zertifikat übereinstimmen, das für das Plugin erstellt wurde.
![\[Ranger-Admin erstellt einen Service.\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/images/ranger-create-service.png)
**Anmerkung**
Das TLS-Zertifikat für dieses Plugin sollte im Trust-Store auf dem Ranger-Admin-Server registriert worden sein. Weitere Details finden Sie unter [TLS-Zertifikate für die Apache Ranger-Integration mit Amazon EMR](emr-ranger-admin-tls.md).
## Erstellen von SparkSQL-Richtlinien
Beim Erstellen einer neuen Richtlinie müssen folgende Felder ausgefüllt werden:
**Richtlinienname**: Der Name dieser Richtlinie.
**Richtlinienbezeichnung**: Eine Bezeichnung, die Sie dieser Richtlinie hinzufügen können.
**Datenbank**: Die Datenbank, für die diese Richtlinie gilt. Der Platzhalter „\$1“ steht für alle Tabellen.
**Tabelle**: Die Tabellen, für die diese Richtlinie gilt. Der Platzhalter „\$1“ steht für alle Tabellen.
**EMR Spark-Spalte**: Die Spalten, für die diese Richtlinie gilt. Der Platzhalter „\$1“ steht für alle Spalten.
**Beschreibung**: Eine Beschreibung dieser Richtlinie.
![\[Ranger-Admin erstellt SparkSQL-Richtliniendetails.\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/images/ranger-create-policy-details.png)
Um die Benutzer und Gruppen anzugeben, geben Sie die Benutzer und Gruppen unten ein, um Berechtigungen zu erteilen. Sie können auch Ausnahmen für die Bedingungen **Zulassen** und **Verweigern** angeben.
![\[Ranger-Admin-SparkSQL-Richtliniendetails lassen Bedingungen zu.\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/images/ranger-create-policy-allow-conditions.png)
Nachdem Sie die Bedingungen für das Zulassen und Verweigern angegeben haben, klicken Sie auf **Speichern.**
## Überlegungen
Jeder Knoten im EMR-Cluster muss eine Verbindung zum Hauptknoten an Port 9 083 herstellen können.
## Einschränkungen
Die folgenden Einschränkungen gelten derzeit für das Apache-Spark-Plugin:
+ Der Record-Server stellt immer eine Verbindung zu HMS her, das auf einem Amazon-EMR-Cluster läuft. Konfigurieren Sie HMS für die Verbindung zum Remote-Modus, falls erforderlich. Sie sollten keine Konfigurationswerte in die Apache-Spark-Konfigurationsdatei Hive-site.xml einfügen.
+ Tabellen, die mit Spark-Datenquellen auf CSV oder Avro erstellt wurden, können mit EMR nicht gelesen werden. RecordServer Verwenden Sie Hive, um Daten zu erstellen und zu schreiben, und lesen Sie sie mit Record.
+ Delta Lake-, Hudi- und Iceberg-Tabellen werden nicht unterstützt.
+ Benutzer müssen Zugriff auf die Standarddatenbank haben. Dies ist eine Voraussetzung für Apache Spark.
+ Der Ranger-Admin-Server unterstützt die automatische Vervollständigung nicht.
+ Das SparkSQL-Plugin für Amazon EMR unterstützt keine Zeilenfilter oder Datenmaskierung.
+ Wenn Sie ALTER TABLE mit Spark SQL verwenden, muss ein Partitionsspeicherort das untergeordnete Verzeichnis eines Tabellenspeicherorts sein. Das Einfügen von Daten in eine Partition, deren Partitionsspeicherort sich von der Tabellenposition unterscheidet, wird nicht unterstützt.
# EMRFS S3-Plugin für die Ranger-Integration mit Amazon EMR
Um die Bereitstellung von Zugriffskontrollen für Objekte in S3 auf einem Multi-Tenant-Cluster zu vereinfachen, bietet das EMRFS-S3-Plugin Zugriffskontrollen für die Daten in S3, wenn über EMRFS darauf zugegriffen wird. Sie können den Zugriff auf S3-Ressourcen auf Benutzer- und Gruppenebene zulassen.
Um dies zu erreichen, sendet EMRFS, wenn Ihre Anwendung versucht, auf Daten innerhalb von S3 zuzugreifen, eine Anfrage nach Anmeldeinformationen an den Secret-Agent-Prozess, wo die Anfrage anhand eines Apache-Ranger-Plugins authentifiziert und autorisiert wird. Wenn die Anfrage autorisiert ist, übernimmt der Secret Agent die IAM-Rolle für Apache-Ranger-Engines mit einer eingeschränkten Richtlinie, um Anmeldeinformationen zu generieren, die nur Zugriff auf die Ranger-Richtlinie haben, die den Zugriff gewährt hat. Die Anmeldeinformationen werden dann an EMRFS zurückgegeben, um auf S3 zuzugreifen.
**Topics**
+ [Unterstützte Features](#emr-ranger-emrfs-features)
+ [Installation der Servicekonfiguration](#emr-ranger-emrfs-service-config)
+ [EMRFS-S3-Richtlinien erstellen](#emr-ranger-emrfs-create-policies)
+ [Hinweise zur Verwendung von EMRFS-S3-Richtlinien](#emr-ranger-emrfs-considerations)
+ [Einschränkungen](#emr-ranger-emrfs-limitations)
## Unterstützte Features
Das EMRFS-S3-Plugin ermöglicht die Autorisierung auf Speicherebene. Richtlinien können erstellt werden, um Benutzern und Gruppen Zugriff auf S3-Buckets und -Präfixe zu gewähren. Die Autorisierung erfolgt nur für EMRFS.
## Installation der Servicekonfiguration
Um die EMRFS-Servicedefinition zu installieren, müssen Sie den Ranger Admin-Server einrichten. Informationen zum Einrichten des Servers finden Sie unter. [Richten Sie einen Ranger Admin-Server für die Integration mit Amazon EMR ein](emr-ranger-admin.md)
Gehen Sie wie folgt vor, um die Apache-Spark-Servicedefinition zu installieren.
**Schritt 1: Stellen Sie eine SSH-Verbindung zum Apache-Ranger-Admin-Server her.**
Beispiel:
```
ssh ec2-user@ip-xxx-xxx-xxx-xxx.ec2.internal
```
**Schritt 2: Laden Sie die EMRFS-Servicedefinition** herunter.
Laden Sie in einem temporären Verzeichnis die Amazon-EMR-Servicedefinition herunter. Diese Servicedefinition wird von Ranger-2.x-Versionen unterstützt.
```
wget https://s3.amazonaws.com/elasticmapreduce/ranger/service-definitions/version-2.0/ranger-servicedef-amazon-emr-emrfs.json
```
**Schritt 3: Registrieren Sie die EMRFS** S3-Servicedefinition.
```
curl -u **:*_<_**_password_ **_for_** _ranger admin user_**_>_* -X POST -d @ranger-servicedef-amazon-emr-emrfs.json \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-k 'https://**:6182/service/public/v2/api/servicedef'
```
Wenn dieser Befehl erfolgreich ausgeführt wird, sehen Sie in der Ranger-Admin-Benutzeroberfläche einen neuen Servicenamens „AMAZON-EMR-S3", wie im folgenden Image gezeigt (Ranger-Version 2.0 wird angezeigt).
![\[Ranger-Admin erstellt einen EMRFS-S3-Service.\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/images/ranger-create-service-EMRFS.png)
**Schritt 4: Erstellen Sie eine Instanz der AMAZON-EMR-EMRFS Anwendung**.
Erstellen Sie eine Instance der Servicedefinition.
+ Klicken Sie auf das **\$1** neben AMAZON-EMR-EMRFS.
Füllen Sie die folgenden Felder aus:
**Servicename (falls angezeigt)**: Der vorgeschlagene Wert ist **amazonemrs3**. Notieren Sie sich diesen Servicenamen, da er für die Erstellung einer EMR-Sicherheitskonfiguration benötigt wird.
**Anzeigename**: Der Name, der für diesen Service angezeigt wird. Der vorgeschlagene Wert ist **amazonemrs3**.
**Allgemeiner Name für das Zertifikat**: Das CN-Feld innerhalb des Zertifikats, das verwendet wird, um von einem Client-Plugin aus eine Verbindung zum Admin-Server herzustellen. Dieser Wert muss mit dem CN-Feld in Ihrem TLS-Zertifikat übereinstimmen, das für das Plugin erstellt wurde.
![\[Ranger-Admin erstellt einen EMRFS-S3-Service.\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/images/ranger-edit-service-EMRFS.png)
**Anmerkung**
Das TLS-Zertifikat für dieses Plugin sollte im Trust-Store auf dem Ranger-Admin-Server registriert worden sein. Weitere Details finden Sie unter [TLS-Zertifikate für die Apache Ranger-Integration mit Amazon EMR](emr-ranger-admin-tls.md).
Wenn der Service erstellt wird, enthält der Service Manager „AMAZON-EMR-EMRFS“, wie in der folgenden Abbildung dargestellt.
![\[Ranger Admin zeigt den neuen EMRFS-S3-Service.\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/images/ranger-new-service-EMRFS.png)
## EMRFS-S3-Richtlinien erstellen
Füllen Sie die folgenden Felder aus, um auf der Seite **Richtlinie erstellen** des Service Managers eine neue Richtlinie zu erstellen.
**Richtlinienname**: Der Name dieser Richtlinie.
**Richtlinienbezeichnung**: Eine Bezeichnung, die Sie dieser Richtlinie hinzufügen können.
**S3-Ressource**: Eine Ressource, die mit dem Bucket und dem optionalen Präfix beginnt. Weitere Informationen finden Sie unter Bewährte Methoden für [Hinweise zur Verwendung von EMRFS-S3-Richtlinien](#emr-ranger-emrfs-considerations). Ressourcen auf dem Ranger-Admin-Server sollten nicht **s3://**, **s3a://** oder **s3n://** enthalten.
![\[Ranger-Admin erstellt einen EMRFS-S3-Service.\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/images/ranger-create-policy-EMRFS.png)
Sie können Benutzer und Gruppen angeben, denen Berechtigungen erteilt werden sollen. Sie können auch Ausnahmen für **Zulassungsbedingungen** und **Verweigerungsbedingungen** angeben.
![\[Ranger Admin zeigt die user/group Berechtigungen für die EMRFS S3-Richtlinie an.\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/images/ranger-permissions-EMRFS.png)
**Anmerkung**
Für jede Richtlinie sind maximal drei Ressourcen zulässig. Das Hinzufügen von mehr als drei Ressourcen kann zu einem Fehler führen, wenn diese Richtlinie auf einem EMR-Cluster verwendet wird. Beim Hinzufügen von mehr als drei Richtlinien wird eine Erinnerung an das Richtlinienlimit angezeigt.
## Hinweise zur Verwendung von EMRFS-S3-Richtlinien
Bei der Erstellung von S3-Richtlinien in Apache Ranger sind einige Nutzungsaspekte zu beachten.
### Berechtigungen für mehrere S3-Objekte
Sie können rekursive Richtlinien und Platzhalterausdrücke verwenden, um mehreren S3-Objekten mit gemeinsamen Präfixen Berechtigungen zu erteilen. Rekursive Richtlinien gewähren allen Objekten mit einem gemeinsamen Präfix Berechtigungen. Platzhalterausdrücke wählen mehrere Präfixe aus. Zusammen gewähren sie allen Objekten mit mehreren gemeinsamen Präfixen, wie in den folgenden Beispielen gezeigt.
**Example Verwenden einer rekursiven Richtlinie**
Angenommen, Sie benötigen Berechtigungen, um alle Parquet-Dateien in einem S3-Bucket aufzulisten, der wie folgt organisiert ist.
```
s3://sales-reports/americas/
+- year=2000
| +- data-q1.parquet
| +- data-q2.parquet
+- year=2019
| +- data-q1.json
| +- data-q2.json
| +- data-q3.json
| +- data-q4.json
|
+- year=2020
| +- data-q1.parquet
| +- data-q2.parquet
| +- data-q3.parquet
| +- data-q4.parquet
| +- annual-summary.parquet
+- year=2021
```
Betrachten Sie zunächst die Parquet-Dateien mit dem Präfix `s3://sales-reports/americas/year=2000`. Sie können allen auf zwei Arten GetObject Berechtigungen gewähren:
**Verwenden von nichtrekursiven Richtlinien**: Eine Option besteht darin, zwei separate nichtrekursive Richtlinien zu verwenden, eine für das Verzeichnis und die andere für die Dateien.
Die erste Richtlinie erteilt die Erlaubnis für das Präfix `s3://sales-reports/americas/year=2020` (es gibt keinen Trailing-`/`).
```
- S3 resource = "sales-reports/americas/year=2000"
- permission = "GetObject"
- user = "analyst"
```
Die zweite Richtlinie verwendet einen Platzhalterausdruck, um allen Dateien mit Präfix Berechtigungen zu erteilen `sales-reports/americas/year=2020/` (beachten Sie das Trailing-`/`).
```
- S3 resource = "sales-reports/americas/year=2020/*"
- permission = "GetObject"
- user = "analyst"
```
**Verwendung einer rekursiven Richtlinie**: Eine bequemere Alternative besteht darin, eine einzige rekursive Richtlinie zu verwenden und dem Präfix rekursive Berechtigungen zu erteilen.
```
- S3 resource = "sales-reports/americas/year=2020"
- permission = "GetObject"
- user = "analyst"
- is recursive = "True"
```
Bisher waren nur die Parquet-Dateien mit dem Präfix `s3://sales-reports/americas/year=2000` enthalten. Sie können jetzt auch die Parquet-Dateien mit einem anderen Präfix, `s3://sales-reports/americas/year=2020`, in dieselben rekursive Richtlinie aufnehmen, indem Sie einen Platzhalterausdruck wie folgt einfügen.
```
- S3 resource = "sales-reports/americas/year=20?0"
- permission = "GetObject"
- user = "analyst"
- is recursive = "True"
```
### Richtlinien für PutObject und DeleteObject Berechtigungen
Das Schreiben von Richtlinien `PutObject` und `DeleteObject` Berechtigungen für Dateien in EMRFS erfordert besondere Sorgfalt, da sie im Gegensatz zu GetObject Berechtigungen zusätzliche rekursive Berechtigungen erfordern, die dem Präfix gewährt werden.
**Example Richtlinien für und Berechtigungen PutObject DeleteObject**
Zum Löschen der Datei ist beispielsweise nicht nur eine DeleteObject Berechtigung für die eigentliche Datei `annual-summary.parquet` erforderlich.
```
- S3 resource = "sales-reports/americas/year=2020/annual-summary.parquet"
- permission = "DeleteObject"
- user = "analyst"
```
Außerdem ist eine Richtlinie erforderlich, die rekursive Rechte `GetObject` und `PutObject` Berechtigungen für das zugehörige Präfix gewährt.
In ähnlicher Weise erfordert das Ändern der Datei `annual-summary.parquet` nicht nur eine `PutObject`-Berechtigung für die eigentliche Datei.
```
- S3 resource = "sales-reports/americas/year=2020/annual-summary.parquet"
- permission = "PutObject"
- user = "analyst"
```
Außerdem ist eine Richtlinie erforderlich, die eine rekursive `GetObject`-Erlaubnis für ihr Präfix erteilt.
```
- S3 resource = "sales-reports/americas/year=2020"
- permission = "GetObject"
- user = "analyst"
- is recursive = "True"
```
### Platzhalter in Richtlinien
Es gibt zwei Bereiche, in denen Platzhalter angegeben werden können. Bei der Angabe einer S3-Ressource können „\$1“ und „?“ verwendet werden. Das „\$1“ ermöglicht einen Abgleich mit einem S3-Pfad und entspricht allem, was hinter dem Präfix steht. Zum Beispiel die folgende Richtlinie.
```
S3 resource = "sales-reports/americas/*"
```
Dies entspricht den folgenden S3-Pfaden.
```
sales-reports/americas/year=2020/
sales-reports/americas/year=2019/
sales-reports/americas/year=2019/month=12/day=1/afile.parquet
sales-reports/americas/year=2018/month=6/day=1/afile.parquet
sales-reports/americas/year=2017/afile.parquet
```
Das Platzhalterzeichen „?“ entspricht nur einem einzelnen Zeichen. Beispielsweise für die Richtlinie.
```
S3 resource = "sales-reports/americas/year=201?/"
```
Dies entspricht den folgenden S3-Pfaden.
```
sales-reports/americas/year=2019/
sales-reports/americas/year=2018/
sales-reports/americas/year=2017/
```
### Platzhalter bei Benutzern
Bei der Zuweisung von Benutzern, die Benutzern Zugriff gewähren sollen, gibt es zwei integrierte Platzhalter. Der erste ist der Platzhalter „\$1USER\$1“, der allen Benutzern Zugriff gewährt. Der zweite Platzhalter ist „\$1OWNER\$1“, der Zugriff auf den Eigentümer eines bestimmten Objekts oder direkt ermöglicht. Der Platzhalter „\$1USER\$1“ wird derzeit jedoch nicht unterstützt.
## Einschränkungen
Die folgenden Einschränkungen gelten derzeit für das EMRFS S3-Plugin:
+ Apache-Ranger-Richtlinien können maximal drei Richtlinien haben.
+ Der Zugriff auf S3 muss über EMRFS erfolgen und kann mit Hadoop-bezogenen Anwendungen verwendet werden. Folgendes wird nicht unterstützt:
– Boto3-Bibliotheken
- AWS SDK und AWK CLI
– S3A-Open-Source-Konnektor
+ Die Ablehnungs-Richtlinien von Apache Ranger werden nicht unterstützt.
+ Vorgänge auf S3 mit Schlüsseln mit CSE-KMS-Verschlüsselung werden derzeit nicht unterstützt.
+ Die Freigabe über Regionsgrenzen hinweg wird nicht unterstützt.
+ Das Sicherheitszone-Feature von Apache Ranger wird nicht unterstützt. Einschränkungen der Zugriffskontrolle, die mit demr Sicherheitszone-Feature definiert wurden, gelten nicht für Ihre Amazon-EMR-Cluster.
+ Der Hadoop-Benutzer generiert keine Audit-Ereignisse, da Hadoop immer auf das EC2-Instance-Profil zugreift.
+ Es wird empfohlen, Amazon EMR Consistency View zu deaktivieren. S3 ist stark konsistent und wird daher nicht mehr benötigt. Weitere Informationen finden Sie unter [Starke Konsistenz von Amazon-S3](https://aws.amazon.com/s3/consistency/).
+ Das EMRFS-S3-Plugin führt zahlreiche STS-Aufrufe durch. Es wird empfohlen, Lasttests auf einem Entwicklungskonto durchzuführen und das STS-Aufrufvolumen zu überwachen. Es wird außerdem empfohlen, eine STS-Anfrage zu stellen, um die AssumeRole Dienstlimits anzuheben.
+ Der Ranger Admin-Server unterstützt die automatische Vervollständigung nicht.
# Trino-Plugin für die Ranger-Integration mit Amazon EMR
Trino (früher PrestoSQL) ist eine SQL-Abfrage-Engine, mit der Sie Abfragen für Datenquellen wie HDFS, Objektspeicher, relationale Datenbanken und NoSQL-Datenbanken ausführen können. Es macht die Migration von Daten an einen zentralen Ort überflüssig und ermöglicht es Ihnen, die Daten von jedem Ort aus abzufragen. Amazon EMR bietet ein Apache- Ranger-Plugin für detaillierte Zugriffskontrollen für Trino. Das Plugin ist mit Admin-Server-Version von Open-Source-Apache-Ranger 2.0 und höher kompatibel.
**Topics**
+ [Unterstützte Features](#emr-ranger-trino-features)
+ [Installation der Servicekonfiguration](#emr-ranger-trino-service-config)
+ [Erstellen von Trino-Richtlinien](#emr-ranger-trino-create-policies)
+ [Überlegungen](#emr-ranger-trino-considerations)
+ [Einschränkungen](#emr-ranger-trino-limitations)
## Unterstützte Features
Das Apache-Ranger-Plugin für Trino auf Amazon EMR unterstützt die gesamte Funktionalität der Trino-Abfrage-Engine, die durch eine detaillierte Zugriffskontrolle geschützt ist. Dazu gehören Zugriffskontrollen auf Datenbank-, Tabellen- und Spaltenebene sowie Zeilenfilterung und Datenmaskierung. Die Richtlinien von Apache Ranger können Richtlinien für die Gewährung und die Ablehnung von Benutzern und Gruppen beinhalten. Prüfereignisse werden auch in CloudWatch Protokolle aufgenommen.
## Installation der Servicekonfiguration
Die Installation der Trino-Servicedefinition erfordert die Einrichtung des Ranger-Admin-Servers. Informationen zum Einrichten des Ranger-Admin-Servers finden Sie unter [Richten Sie einen Ranger Admin-Server für die Integration mit Amazon EMR ein](emr-ranger-admin.md).
Zum Installieren der Trino-Servicedefinition führen Sie die folgenden Schritte aus.
1. Stellen Sie eine SSH-Verbindung zum Apache-Ranger-Admin-Server her.
```
ssh ec2-user@ip-xxx-xxx-xxx-xxx.ec2.internal
```
1. Deinstallieren Sie das Presto-Server-Plugin, falls es existiert. Führen Sie den folgenden Befehl aus. Wenn dieser Fehler mit der Fehlermeldung „Service nicht gefunden“ angezeigt wird, bedeutet dies, dass das Presto-Server-Plugin nicht auf Ihrem Server installiert wurde. Fahren Sie mit dem nächsten Schritt fort.
```
curl -f -u **:*_<_**_password_ **_for_** _ranger admin user_**_>_* -X DELETE -k 'https://**:6182/service/public/v2/api/servicedef/name/presto'
```
1. Laden Sie die Servicedefinition und das Apache-Ranger-Admin-Server-Plugin herunter. Laden Sie die Servicedefinition in einem temporären Verzeichnis herunter. Diese Servicedefinition wird von Ranger-2.x-Versionen unterstützt.
```
wget https://s3.amazonaws.com/elasticmapreduce/ranger/service-definitions/version-2.0/ranger-servicedef-amazon-emr-trino.json
```
1. Registrieren Sie die Apache-Spark-Servicedefinition für Amazon EMR
```
curl -u **:*_<_**_password_ **_for_** _ranger admin user_**_>_* -X POST -d @ranger-servicedef-amazon-emr-trino.json \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-k 'https://**:6182/service/public/v2/api/servicedef'
```
Wenn dieser Befehl erfolgreich ausgeführt wird, wird in Ihrer Ranger-Admin-Benutzeroberfläche ein neuer Service mit dem Namen `TRINO` angezeigt, wie in der folgenden Abbildung dargestellt.
![\[Ranger-Admin erstellt einen Service.\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/images/ranger-create-service-trino.png)
1. Erstellen Sie eine Instance der `TRINO`-Anwendung und geben Sie die folgenden Informationen ein.
**Servicename**: Der Servicename, den Sie verwenden werden. Der vorgeschlagene Wert ist `amazonemrtrino`. Notieren Sie sich diesen Servicenamen, da er für die Erstellung einer Amazon-EMR-Sicherheitskonfiguration benötigt wird.
**Anzeigename:** Der Name, der für diese Instance angezeigt werden soll. Der vorgeschlagene Wert ist `amazonemrtrino`.
![\[Ranger-Admin-Anzeigename.\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/images/ranger-display-name-trino.png)
**jdbc.driver. ClassName**: Der Klassenname der JDBC-Klasse für Trino-Konnektivität. Sie können den Standardwert verwenden.
**jdbc**.url: Die JDBC-Verbindungszeichenfolge, die verwendet werden soll, wenn eine Verbindung zum Trino-Koordinator hergestellt wird.
**Allgemeiner Name für das Zertifikat**: Das CN-Feld innerhalb des Zertifikats, das verwendet wird, um von einem Client-Plugin aus eine Verbindung zum Admin-Server herzustellen. Dieser Wert muss mit dem CN-Feld in Ihrem TLS-Zertifikat übereinstimmen, das für das Plugin erstellt wurde.
![\[Allgemeiner Name für Ranger Admin.\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/images/ranger-common-name-trino.png)
Das TLS-Zertifikat für dieses Plugin sollte im Trust-Store auf dem Ranger-Admin-Server registriert worden sein. Weitere Informationen finden Sie unter [TLS-Zertifikate](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-ranger-admin-tls.html).
## Erstellen von Trino-Richtlinien
Wenn Sie eine neue Richtlinie erstellen, füllen Sie die folgenden Felder aus.
**Richtlinienname**: Der Name dieser Richtlinie.
**Richtlinienbezeichnung**: Eine Bezeichnung, die Sie dieser Richtlinie hinzufügen können.
**Tabelle**: Die Tabellen, für die diese Richtlinie gilt. Der Platzhalter „\$1“ steht für alle Tabellen.
**Schema**: Die Schemas, für die diese Richtlinie gilt. Der Platzhalter „\$1“ steht für alle Schemas.
**Tabelle**: Die Tabellen, für die diese Richtlinie gilt. Der Platzhalter „\$1“ steht für alle Tabellen.
**Spalte**: Die Spalten, für die diese Richtlinie gilt. Der Platzhalter „\$1“ steht für alle Spalten.
**Beschreibung**: Eine Beschreibung dieser Richtlinie.
Andere Arten von Richtlinien gibt es für den **Trino-Benutzer** (für den Zugriff, der sich als Benutzer ausgibt), die **Trino-System-/Sitzungseigenschaft (für die Änderung der System- oder Sitzungseigenschaften der Engine)**, für **Funktionen/Prozeduren** (für das Zulassen von Funktions- oder Prozeduraufrufen) und die **URL** (für die Gewährung von Lese-/Schreibzugriff auf die Engine an Datenspeicherorten).
![\[Ranger-Admin erstellt SparkSQL-Richtliniendetails.\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/images/ranger-create-policy-details-trino.png)
Um die Benutzer und Gruppen anzugeben, geben Sie die Benutzer und Gruppen unten ein, um Berechtigungen zu erteilen. Sie können auch Ausnahmen für **Zulassungsbedingungen** und **Verweigerungsbedingungen** angeben.
![\[Ranger-Admin-SparkSQL-Richtliniendetails lassen Bedingungen zu.\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/images/ranger-create-policy-allow-conditions-trino.png)
Nachdem Sie die Bedingungen für das Zulassen und Verweigern angegeben haben, klicken Sie auf **Speichern**.
## Überlegungen
Bei der Erstellung von Trino-Richtlinien in Apache Ranger sind einige Nutzungsaspekte zu beachten.
**Hive-Metadatenserver**
Auf den Hive-Metadatenserver können nur vertrauenswürdige Engines zugreifen, insbesondere die Trino-Engine, um sich vor unbefugtem Zugriff zu schützen. Auf den Hive-Metadatenserver greifen auch alle Knoten im Cluster zu. Der erforderliche Port 9 083 ermöglicht allen Knoten den Zugriff auf den Hauptknoten.
**Authentifizierung**
Standardmäßig ist Trino so konfiguriert, dass es sich mithilfe von Kerberos authentifiziert, wie in der Amazon-EMR-Sicherheitskonfiguration konfiguriert.
**Verschlüsselung während der Übertragung erforderlich**
Für das Trino-Plugin müssen Sie die Verschlüsselung während der Übertragung in der Amazon-EMR-Sicherheitskonfiguration aktiviert haben. Informationen zum Aktivieren der Verschlüsselung finden Sie unter [Verschlüsselung während der Übertragung](emr-data-encryption-options.md#emr-encryption-intransit).
## Einschränkungen
Im Folgenden sind die aktuellen Einschränkungen des Trino-Plugins aufgeführt:
+ Der Ranger-Admin-Server unterstützt die automatische Vervollständigung nicht.
# Fehlerbehebung für Apache Ranger
Im Folgenden finden Sie einige häufig diagnostizierte Probleme im Zusammenhang mit der Verwendung von Apache Ranger.
## Empfehlungen
+ **Testen Sie mit einem einzigen Hauptknotencluster:** Master-Cluster mit einem Knoten können schneller bereitgestellt werden als ein Cluster mit mehreren Knoten, wodurch die Zeit für jede Test-Iteration verkürzt werden kann.
+ **Stellen Sie den Entwicklungsmodus auf dem Cluster ein.** Wenn Sie Ihren EMR-Cluster starten, setzen Sie den `--additional-info"`-Parameter auf:
`'{"clusterType":"development"}'`
Dieser Parameter kann nur über die AWS CLI oder das AWS SDK festgelegt werden und ist nicht über die Amazon EMR-Konsole verfügbar. Wenn dieses Flag gesetzt ist und der Master nicht bereitstellen kann, hält der Amazon-EMR-Service den Cluster für einige Zeit am Leben, bevor er außer Betrieb genommen wird. Diese Zeit ist sehr nützlich, um verschiedene Protokolldateien zu überprüfen, bevor der Cluster beendet wird.
# EMR-Cluster konnte nicht bereitgestellt werden
Es gibt mehrere Gründe, warum ein Amazon-EMR-Cluster möglicherweise nicht gestartet werden kann. Im Folgenden finden Sie einige Möglichkeiten, das Problem zu diagnostizieren.
**Überprüfen Sie die EMR-Bereitstellungsprotokolle**
Amazon EMR verwendet Puppet, um Anwendungen auf einem Cluster zu installieren und zu konfigurieren. Anhand der Protokolle erhalten Sie Informationen darüber, ob während der Bereitstellungsphase eines Clusters Fehler aufgetreten sind. Auf die Protokolle kann auf dem Cluster oder in S3 zugegriffen werden, wenn die Protokolle so konfiguriert sind, dass sie an S3 übertragen werden.
Die Protokolle werden auf der Festplatte `/var/log/provision-node/apps-phase/0/{UUID}/puppet.log` und `s3:////node//provision-node/apps-phase/0/{UUID}/puppet.log.gz.` gespeichert.
**Allgemeine Fehlermeldungen**
| Fehlermeldung | Ursache |
| --- | --- |
| Puppet (err): Der Systemd-Start für ist fehlgeschlagen\$1 emr-record-server journalctl-Protokoll für: emr-record-server | EMR Record Server konnte nicht gestartet werden. Weitere Informationen finden Sie unten in den EMR-Record-Server-Protokollen. |
| Puppet (err): Der Systemd-Start für ist fehlgeschlagen\$1 emr-record-server journalctl-Protokoll für emrsecretagent: | EMR Record Server konnte nicht gestartet werden. Weitere Informationen finden Sie weiter unten unter Secret-Agent-Protokolle überprüfen. |
| /Stage [main] /Ranger\$1Plugins: :Ranger\$1Hive\$1 (Hinweis): 140408606197664:Fehler:0906d06c:PEM-Routinen:PEM\$1READ\$1BIO:Keine Startzeile:PEM\$1LIB.C:707:Erwartet: JEDER PRIVATE SCHLÜSSEL plugin/Ranger\$1plugins::Prepare\$1two\$1way\$1tls[configure 2-way TLS in Hive plugin]/Exec[create keystore and truststore for Ranger Hive plugin]/returns | Das private TLS-Zertifikat in Secret Manager für das Apache Ranger-Plug-in-Zertifikat hat nicht das richtige Format oder ist kein privates Zertifikat. Informationen zu [TLS-Zertifikate für die Apache Ranger-Integration mit Amazon EMR](emr-ranger-admin-tls.md) den Zertifikatsformaten finden Sie unter. |
| /Stage [main] /Ranger\$1Plugins: :Ranger\$1S3\$1 plugin/Ranger\$1plugins::Prepare\$1two\$1way\$1tls[configure 2-way TLS in Ranger s3 plugin]/Exec[create keystore and truststore for Ranger amazon-emr-s3 plugin]/returns (notice): An error occurred (AccessDeniedException) when calling the GetSecretValue operation: User: arn:aws:sts::XXXXXXXXXXX:assumed-role/EMR\$1EC2\$1DefaultRole/i -XXXXXXXXXXXX ist nicht berechtigt, Folgendes auszuführen: secretsmanager: GetSecretValue on resource: arn:aws:secretsmanager:us-east-1:xxxxxxxxxx:secret: -XXXXX AdminServer | Die EC2-Instance-Profilrolle verfügt nicht über die richtigen Berechtigungen, um die TLS-Zertifikate von Secrets Agent abzurufen. |
** SecretAgent Überprüfen Sie die Protokolle**
Secret-Agent-Protokolle befinden sich in `/emr/secretagent/log/` auf einem EMR-Knoten oder im `s3:////node//daemons/secretagent/`-Verzeichnis in S3.
**Allgemeine Fehlermeldungen**
| Fehlermeldung | Ursache |
| --- | --- |
| Ausnahme im Thread „main“ com.amazonaws.services.securitytoken.model. AWSSecurityTokenServiceException: Benutzer: arn:aws:sts: :XXXXXXXXXXXX:assumed- role/EMR\$1EC2\$1DefaultRole/i -XXXXXXXXXXXXXXX ist nicht berechtigt, Folgendes auszuführen: sts: AssumeRole on resource: arn:aws:iam: RangerPluginDataAccessRole :XXXXXXXXXXXX:role/\$1 (Service: AWSSecurityTokenService; Statuscode: 403; Fehlercode:; Fehlercode:; Anforderungs-ID: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX; Proxy: null) AccessDenied | Die obige Ausnahme bedeutet, dass die EMR EC2-Instance-Profilrolle nicht berechtigt ist, die Rolle zu übernehmen. **RangerPluginDataAccessRole** Siehe [IAM-Rollen für die native Integration mit Apache Ranger](emr-ranger-iam.md). |
| FEHLER qtp54617902-149: Eine Web-App-Ausnahme ist aufgetreten javax.ws.rs. NotAllowedException: HTTP 405-Methode nicht erlaubt | Diese Fehler können ignoriert werden. |
**Überprüfen Sie die Record-Serverprotokolle (für SparkSQL)**
EMR Record Server-Protokolle sind auf einem EMR-Knoten unter/var/log/emr-record-server/ oder im Verzeichnis s3:////node/ /daemons///in S3 verfügbar. emr-record-server
**Allgemeine Fehlermeldungen**
| Fehlermeldung | Ursache |
| --- | --- |
| InstanceMetadataServiceResourceFetcherEMR Record Server-Protokolle sind unter/-record-server/ auf einem EMR-Knoten verfügbar, oder sie befinden sich im Verzeichnis s3:////node/ /daemons///in S3. ----sep----:105 - [] Token com.amazonaws konnte nicht abgerufen werden. SdkClientException: Es konnte keine Verbindung zum Service-Endpunkt hergestellt werden | Das EMR SecretAgent wurde nicht angezeigt oder es liegt ein Problem vor. Untersuchen Sie die SecretAgent Protokolle auf Fehler und überprüfen Sie das Puppet-Skript, um festzustellen, ob Bereitstellungsfehler aufgetreten sind. |
# Abfragen für die Ranger-Integration mit Amazon EMR schlagen unerwartet fehl
**Überprüfen Sie die Protokolle des Apache Ranger-Plug-ins (Apache Hive, EMRRecordServer, EMR usw. SecretAgent, Protokolle)**
Dieser Abschnitt gilt für alle Anwendungen, die in das Ranger-Plugin integriert sind, wie Apache Hive, EMR Record Server und EMR. SecretAgent
**Allgemeine Fehlermeldungen**
| Fehlermeldung | Ursache |
| --- | --- |
| ERROR:272 PolicyRefresher - [] (PolicyRefresherserviceName=policy-repository): Der Dienst konnte nicht gefunden werden. Löscht den lokalen Richtliniencache (-1) | Diese Fehlermeldungen bedeuten, dass der Servicename, den Sie in der EMR-Sicherheitskonfiguration angegeben haben, nicht mit einem Service-Richtlinien-Repository auf dem Ranger-Admin-Server übereinstimmt. |
Wenn Ihr AMAZON-EMR-SPARK Dienst auf dem Ranger Admin-Server wie folgt aussieht, sollten Sie ihn als Dienstnamen eingeben. **amazonemrspark**
![\[Der Ranger Admin-Server zeigt AMAZON-EMR-SPARK die Fehlerbehebung an.\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/images/ranger-amazon-emr-spark-troubleshooting.png)
# Steuern Sie den Netzwerkverkehr mit Sicherheitsgruppen für Ihren Amazon EMR-Cluster
Sicherheitsgruppen dienen als virtuelle Firewalls für die EC2-Instances in Ihrem Cluster, um den ein- und ausgehenden Datenverkehr zu kontrollieren. Für jede Sicherheitsgruppe gibt es einen Satz von Regeln zur Kontrolle des eingehenden Datenverkehrs und einen Satz von Regeln zur Kontrolle des ausgehenden Datenverkehrs. Weitere Informationen finden Sie unter [Amazon-EC2-Sicherheitsgruppen für Linux-Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html) im *Amazon-EC2-Benutzerhandbuch*.
Sie verwenden zwei Klassen von Sicherheitsgruppen mit Amazon EMR: * Amazon-EMR-verwaltete Sicherheitsgruppen* und *zusätzliche Sicherheitsgruppen*.
Mit jedem Cluster sind verwaltete Sicherheitsgruppen verknüpft. Sie können die standardmäßigen verwalteten Sicherheitsgruppen die Amazon EMR erstellt oder benutzerdefinierte verwaltete Sicherheitsgruppen angeben. In beiden Fällen fügt Amazon EMR automatisch Regeln zu verwalteten Sicherheitsgruppen hinzu, die ein Cluster für die Kommunikation zwischen Cluster-Instances und AWS Services benötigt.
Zusätzliche Sicherheitsgruppen sind optional. Sie können sie zusätzlich zu den verwalteten Sicherheitsgruppen angeben, um den Zugriff auf Cluster-Instances anzupassen. Zusätzliche Sicherheitsgruppen enthalten nur von Ihnen definierte Regeln. Amazon EMR ändert sie nicht.
Die von Amazon EMR in verwalteten Sicherheitsgruppen erstellten Regeln gestatten dem Cluster nur die Kommunikation zwischen internen Komponenten. Um Benutzern und Anwendungen den Zugriff auf einen Cluster von außerhalb des Clusters zu ermöglichen, können Sie Regeln in verwalteten Sicherheitsgruppen bearbeiten, zusätzliche Sicherheitsgruppen mit zusätzlichen Regeln erstellen oder beides ausführen.
**Wichtig**
Das Bearbeiten von Regeln in verwalteten Sicherheitsgruppen kann unbeabsichtigte Folgen haben. Möglicherweise blockieren Sie versehentlich den Datenverkehr, der für die ordnungsgemäße Funktion der Cluster erforderlich ist, und verursachen Fehler, da die Knoten nicht erreichbar sind. Planen und testen Sie Sicherheitsgruppenkonfigurationen sorgfältig, bevor Sie diese implementieren.
Sie können Sicherheitsgruppen nur während der Erstellung eines Clusters angeben. Sie können keine Sicherheitsgruppen zu Clustern oder Cluster-Instances hinzufügen, während ein Cluster ausgeführt wird. Sie können jedoch Regeln in vorhandenen Sicherheitsgruppen bearbeiten, hinzufügen und entfernen. Die Regeln treten in Kraft, sobald Sie sie speichern.
Sicherheitsgruppen sind standardmäßig einschränkend. Wenn keine Regel hinzugefügt wird, die Datenverkehr zulässt, wird der Datenverkehr zurückgewiesen. Wenn es mehr als eine Regel für denselben Datenverkehr und dieselbe Quelle gibt, wird die toleranteste Regel angewendet. Wenn es beispielsweise eine Regel gibt, die SSH-Verbindungen von der IP-Adresse 192.0.2.12/32 zulässt, und eine weitere Regel, die dem gesamten TCP-Datenverkehr Zugriff aus dem Bereich 192.0.2.0/24 gewährt, hat die Regel Vorrang, die dem gesamten TCP-Datenverkehr aus dem Bereich Zugriff gewährt, der 192.0.2.12 einschließt. In diesem Fall könnte der Client unter 192.0.2.12 mehr Zugriff erhalten als beabsichtigt.
**Wichtig**
Seien Sie vorsichtig, wenn Sie Regeln für offene Ports für Sicherheitsgruppen bearbeiten. Stellen Sie sicher, dass Sie Regeln hinzufügen, die nur Datenverkehr von vertrauenswürdigen und authentifizierten Clients für die Protokolle und Ports zulassen, die zum Ausführen Ihrer Workloads erforderlich sind.
Sie können Amazon EMR *Block Public Access* in jeder Region konfigurieren, die Sie verwenden, um die Cluster-Erstellung zu verhindern, wenn eine Regel den öffentlichen Zugriff auf beliebige Ports zulässt, die Sie nicht einer Liste von Ausnahmen hinzufügen. Für AWS Konten, die nach Juli 2019 erstellt wurden, ist Amazon EMR Block Public Access standardmäßig aktiviert. Für AWS Konten, die vor Juli 2019 einen Cluster erstellt haben, ist Amazon EMR Block Public Access standardmäßig deaktiviert. Weitere Informationen finden Sie unter [Verwenden von Amazon EMR Block Public Access](emr-block-public-access.md).
**Topics**
+ [Arbeiten mit von Amazon EMR verwalteten Sicherheitsgruppen](emr-man-sec-groups.md)
+ [Arbeiten mit zusätzlichen Sicherheitsgruppen für einen Amazon EMR-Cluster](emr-additional-sec-groups.md)
+ [Angeben von Amazon-EMR-verwalteten und zusätzlichen Sicherheitsgruppen](emr-sg-specify.md)
+ [Angeben von EC2-Sicherheitsgruppen für EMR Notebooks](emr-managed-notebooks-security-groups.md)
+ [Verwenden von Amazon EMR Block Public Access](emr-block-public-access.md)
**Anmerkung**
Amazon EMR ist bestrebt, integrative Alternativen für potenziell anstößige oder nicht inklusive Branchenbegriffe wie „Master“ und „Slave“ zu verwenden. Wir haben auf eine neue Terminologie umgestellt, um ein umfassenderes Erlebnis zu bieten und Ihnen das Verständnis der Servicekomponenten zu erleichtern.
Wir beschreiben „Knoten“ jetzt als **Instances** und Amazon-EMR-Instance-Typen als **Primär**, **Core**, und **Aufgaben-Instances**. Während der Umstellung finden Sie möglicherweise immer noch ältere Verweise auf die veralteten Begriffe, z. B. solche, die sich auf Sicherheitsgruppen für Amazon EMR beziehen.
# Arbeiten mit von Amazon EMR verwalteten Sicherheitsgruppen
**Anmerkung**
Amazon EMR ist bestrebt, integrative Alternativen für potenziell anstößige oder nicht inklusive Branchenbegriffe wie „Master“ und „Slave“ zu verwenden. Wir haben auf eine neue Terminologie umgestellt, um ein umfassenderes Erlebnis zu bieten und Ihnen das Verständnis der Servicekomponenten zu erleichtern.
Wir beschreiben „Knoten“ jetzt als **Instances** und Amazon-EMR-Instance-Typen als **Primär**, **Core**, und **Aufgaben-Instances**. Während der Umstellung finden Sie möglicherweise immer noch ältere Verweise auf die veralteten Begriffe, z. B. solche, die sich auf Sicherheitsgruppen für Amazon EMR beziehen.
Mit der Primär-Instance und den Core- und Aufgaben-Instances in einem Cluster sind verschiedene verwaltete Sicherheitsgruppen verknüpft. Sie benötigen eine zusätzliche verwaltete Sicherheitsgruppe für den Servicezugriff, wenn Sie einen Cluster in einem privaten Subnetz erstellen. Weitere Informationen zur Rolle von verwalteten Sicherheitsgruppen in Bezug auf Ihre Netzwerkkonfiguration finden Sie unter [Amazon VPC-Optionen beim Starten eines Clusters](emr-clusters-in-a-vpc.md).
Wenn Sie verwaltete Sicherheitsgruppen für einen Cluster angeben, müssen Sie für alle verwalteten Sicherheitsgruppen denselben Typ von Sicherheitsgruppe (Standard oder benutzerdefiniert) verwenden. Sie können beispielsweise nicht eine benutzerdefinierte Sicherheitsgruppe für die Primär-Instance angeben und dann keine benutzerdefinierte Sicherheitsgruppe für die Core- und Aufgaben-Instances angeben.
Wenn Sie standardmäßige verwaltete Sicherheitsgruppen verwenden, müssen Sie diese beim Erstellen eines Clusters nicht angeben. Amazon EMR verwendet automatisch die Standardeinstellungen. Wenn die Standardeinstellungen in der VPC des Clusters noch nicht vorhanden sind, werden sie außerdem von Amazon EMR erstellt. Amazon EMR erstellt sie auch, wenn Sie sie explizit angeben und sie noch nicht existieren.
Sie können die Regeln in verwalteten Sicherheitsgruppen nach der Erstellung der Cluster bearbeiten. Wenn Sie einen neuen Cluster erstellen, überprüft Amazon EMR die Regeln in den von Ihnen angegebenen verwalteten Sicherheitsgruppen und erstellt dann alle fehlenden *eingehenden* Regeln, die der neue Cluster zusätzlich zu den Regeln benötigt, die möglicherweise zuvor hinzugefügt wurden. Sofern nicht anders definiert, werden alle Regeln, die für standardmäßig Amazon-EMR-verwaltete Sicherheitsgruppen gelten, auch den von Ihnen angegebenen benutzerdefinierten von Amazon EMR verwaltete n Sicherheitsgruppen hinzugefügt.
Die standardmäßigen verwalteten Sicherheitsgruppen sind:
+ **ElasticMapReduce-primär**
Informationen zu den Regeln in dieser Sicherheitsgruppe finden Sie unter [Von Amazon EMR verwaltete Sicherheitsgruppe für die primäre Instance (öffentliche Subnetze)](#emr-sg-elasticmapreduce-master).
+ **ElasticMapReduce-Kern**
Informationen zu den Regeln in dieser Sicherheitsgruppe finden Sie unter [Von Amazon EMR verwaltete Sicherheitsgruppe für Core- und Aufgaben-Instances (öffentliche Subnetze)](#emr-sg-elasticmapreduce-slave).
+ **ElasticMapReduce-Primär-Privat**
Informationen zu den Regeln in dieser Sicherheitsgruppe finden Sie unter [Von Amazon EMR verwaltete Sicherheitsgruppe für die Master-Instance (private Subnetze)](#emr-sg-elasticmapreduce-master-private).
+ **ElasticMapReduce-Core-Privat**
Informationen zu den Regeln in dieser Sicherheitsgruppe finden Sie unter [Von Amazon EMR verwaltete Sicherheitsgruppe für Core- und Aufgaben-Instances (private Subnetze)](#emr-sg-elasticmapreduce-slave-private).
+ **ElasticMapReduce-ServiceAccess**
Informationen zu den Regeln in dieser Sicherheitsgruppe finden Sie unter [Von Amazon EMR verwaltete Sicherheitsgruppe für den Servicezugriff (private Subnetze)](#emr-sg-elasticmapreduce-sa-private).
## Von Amazon EMR verwaltete Sicherheitsgruppe für die primäre Instance (öffentliche Subnetze)
**Die standardmäßig verwaltete Sicherheitsgruppe für die primäre Instance in öffentlichen Subnetzen hat den **Gruppennamen** -primary. ElasticMapReduce** Sie hat die folgenden Regeln. Wenn Sie eine benutzerdefinierte verwaltete Sicherheitsgruppe angeben, fügt Amazon EMR Ihrer benutzerdefinierten Sicherheitsgruppe dieselben Regeln hinzu.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/emr-man-sec-groups.html)
**Um vertrauenswürdigen Quellen SSH-Zugriff auf die primäre Sicherheitsgruppe mit der Konsole zu gewähren**
Um Ihre Sicherheitsgruppen zu bearbeiten, benötigen Sie die Berechtigung, Sicherheitsgruppen für die VPC zu verwalten, in der sich der Cluster befindet. Weitere Informationen finden Sie im *IAM-Benutzerhandbuch* unter [Ändern von Benutzerberechtigungen](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html) und unter [Beispielrichtlinie](https://docs.aws.amazon.com//IAM/latest/UserGuide/reference_policies_examples_ec2_securitygroups-vpc.html), die die Verwaltung von EC2-Sicherheitsgruppen ermöglicht.
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon EMR-Konsole unter [https://console.aws.amazon.com/emr](https://console.aws.amazon.com/emr).
1. Klicken Sie auf **Cluster**. Wählen Sie die **ID** des Clusters aus, den Sie ändern möchten.
1. Erweitern Sie im Bereich **Netzwerk und Sicherheit** das Dropdownmenü **EC2-Sicherheitsgruppen (Firewall)**.
1. Wählen Sie unter **Primärer Knoten** Ihre Sicherheitsgruppe aus.
1. Wählen Sie **Edit inbound rules** (Regeln für eingehenden Datenverkehr bearbeiten) aus.
1. Suchen Sie mit den folgenden Einstellungen nach einer Regel für eingehenden Datenverkehr, die öffentlichen Zugriff ermöglicht. Falls sie existiert, wählen Sie **Löschen**, um sie zu entfernen.
+ **Typ**
SSH
+ **Port**
22
+ **Quelle**
Benutzerdefiniert 0.0.0.0/0
**Warnung**
Vor Dezember 2020 gab es eine vorkonfigurierte Regel, die eingehenden Datenverkehr auf Port 22 aus allen Quellen zuließ. Diese Regel wurde erstellt, um die ersten SSH-Verbindungen zum Primärknoten zu vereinfachen. Wir empfehlen Ihnen dringend, diese Eingangsregel zu entfernen und den Datenverkehr auf vertrauenswürdige Quellen zu beschränken.
1. Scrollen Sie zum Ende der Regelliste und wählen Sie **Regel hinzufügen**.
1. Wählen Sie für **Type (Typ)** **SSH** aus.
Wenn Sie SSH auswählen, wird automatisch **TCP** für **Protokoll** und **22** für **Portbereich** eingegeben.
1. Wählen Sie als Quelle **Meine IP** aus, um Ihre IP-Adresse automatisch als Quelladresse hinzuzufügen. Sie können auch einen Bereich **benutzerdefinierter** vertrauenswürdiger Client-IP-Adressen hinzufügen oder zusätzliche Regeln für andere Clients erstellen. In vielen Netzwerkumgebungen werden IP-Adressen dynamisch zugewiesen, sodass Sie in Zukunft möglicherweise Ihre IP-Adressen für vertrauenswürdige Clients aktualisieren müssen.
1. Wählen Sie **Speichern**.
1. Wählen Sie optional im Bereich **Netzwerk und Sicherheit unter **Kern- und Taskknoten** die andere Sicherheitsgruppe aus und** wiederholen Sie die obigen Schritte, um dem SSH-Client den Zugriff auf Core- und Taskknoten zu ermöglichen.
## Von Amazon EMR verwaltete Sicherheitsgruppe für Core- und Aufgaben-Instances (öffentliche Subnetze)
**Die standardmäßig verwaltete Sicherheitsgruppe für Core- und Task-Instances in öffentlichen Subnetzen hat den **Gruppennamen** -core. ElasticMapReduce** Für die verwaltete Standardsicherheitsgruppe gelten die folgenden Regeln. Amazon EMR fügt die gleichen Regeln hinzu, wenn Sie eine benutzerdefinierte verwaltete Sicherheitsgruppe angeben.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/emr-man-sec-groups.html)
## Von Amazon EMR verwaltete Sicherheitsgruppe für die Master-Instance (private Subnetze)
**Die standardmäßig verwaltete Sicherheitsgruppe für die primäre Instanz in privaten Subnetzen hat den **Gruppennamen** -Primary-Private. ElasticMapReduce** Für die verwaltete Standardsicherheitsgruppe gelten die folgenden Regeln. Amazon EMR fügt die gleichen Regeln hinzu, wenn Sie eine benutzerdefinierte verwaltete Sicherheitsgruppe angeben.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/emr-man-sec-groups.html)
## Von Amazon EMR verwaltete Sicherheitsgruppe für Core- und Aufgaben-Instances (private Subnetze)
**Die standardmäßig verwaltete Sicherheitsgruppe für Core- und Task-Instances in privaten Subnetzen hat den **Gruppennamen** -Core-Private. ElasticMapReduce** Für die verwaltete Standardsicherheitsgruppe gelten die folgenden Regeln. Amazon EMR fügt die gleichen Regeln hinzu, wenn Sie eine benutzerdefinierte verwaltete Sicherheitsgruppe angeben.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/emr-man-sec-groups.html)
### Regeln für ausgehenden Datenverkehr bearbeiten
Standardmäßig erstellt Amazon EMR diese Sicherheitsgruppe mit ausgehenden Regeln, die den gesamten ausgehenden Datenverkehr auf allen Protokollen und Ports zulassen. Das Zulassen des gesamten ausgehenden Datenverkehrs ist ausgewählt, da für verschiedene Amazon-EMR- und Kundenanwendungen, die auf Amazon-EMR-Clustern ausgeführt werden können, möglicherweise unterschiedliche Ausgangsregeln erforderlich sind. Amazon EMR kann diese spezifischen Einstellungen bei der Erstellung von Standardsicherheitsgruppen nicht antizipieren. Sie können den ausgehenden Datenverkehr in Ihren Sicherheitsgruppen einschränken, sodass nur die Regeln berücksichtigt werden, die Ihren Anwendungsfällen und Sicherheitsrichtlinien entsprechen. Für diese Sicherheitsgruppe sind mindestens die folgenden Regeln für ausgehenden Datenverkehr erforderlich, für einige Anwendungen sind jedoch möglicherweise zusätzliche Regeln für ausgehenden Datenverkehr erforderlich.
| Typ | Protocol (Protokoll) | Port-Bereich | Ziel | Details |
| --- | --- | --- | --- | --- |
| Alle TCP | TCP | Alle | pl- xxxxxxxx | Verwaltete Präfixliste von Amazon S3 com.amazonaws.MyRegion.s3. |
| Gesamter Datenverkehr | Alle | Alle | sg- xxxxxxxxxxxxxxxxx | Die ID der Sicherheitsgruppe ElasticMapReduce-Core-Private. |
| Gesamter Datenverkehr | Alle | Alle | sg- xxxxxxxxxxxxxxxxx | Die ID der Sicherheitsgruppe ElasticMapReduce-Primary-Private. |
| Custom TCP | TCP | 9443 | sg- xxxxxxxxxxxxxxxxx | Die ID der Sicherheitsgruppe ElasticMapReduce-ServiceAccess. |
## Von Amazon EMR verwaltete Sicherheitsgruppe für den Servicezugriff (private Subnetze)
Die standardmäßig verwaltete Sicherheitsgruppe für den Dienstzugriff in privaten Subnetzen hat den **Gruppennamen ElasticMapReduce** **- ServiceAccess**. Sie besitzt Regeln für den eingehenden und den ausgehenden Datenverkehr, die Datenverkehr über HTTPS (Port 8443, Port 9443) mit den anderen verwalteten Sicherheitsgruppen in privaten Subnetzen zulassen. Diese Regeln ermöglichen dem Cluster-Manager die Kommunikation mit dem Primärknoten und mit Kern- und Aufgabenknoten. Dieselben Regeln sind erforderlich, wenn Sie benutzerdefinierte Sicherheitsgruppen verwenden.
| Typ | Protocol (Protokoll) | Port-Bereich | Quelle | Details |
| --- | --- | --- | --- | --- |
| Regeln für eingehenden Datenverkehr Erforderlich für EMR-Cluster mit Amazon EMR ab Version 5.30.0. |
| Custom TCP | TCP | 9443 | Die Gruppen-ID der verwalteten Sicherheitsgruppe für die Primär-Instance. | Diese Regel ermöglicht die Kommunikation zwischen der Sicherheitsgruppe der Primär-Instance und der Sicherheitsgruppe des Servicezugriffs. |
| Regeln für ausgehenden Datenverkehr erforderlich für alle Amazon-EMR-Cluster |
| Custom TCP | TCP | 8443 | Die Gruppen-ID der verwalteten Sicherheitsgruppe für die Primär-Instance. | Diese Regeln ermöglichen dem Cluster-Manager die Kommunikation mit dem Primärknoten und mit Kern- und Aufgabenknoten. |
| Custom TCP | TCP | 8443 | Die Gruppen-ID der verwalteten Sicherheitsgruppe für Core- und Aufgaben-Instances. | Diese Regeln ermöglichen dem Cluster-Manager die Kommunikation mit dem Primärknoten und mit Kern- und Aufgabenknoten. |
# Arbeiten mit zusätzlichen Sicherheitsgruppen für einen Amazon EMR-Cluster
Sie können zusätzliche Sicherheitsgruppen unabhängig davon verwenden, ob Sie die standardmäßigen verwalteten Sicherheitsgruppen verwenden oder benutzerdefinierte verwaltete Sicherheitsgruppen angeben. Mit zusätzlichen Sicherheitsgruppen können Sie den Zugriff auf die einzelnen Cluster und von externen Clients, Ressourcen und Anwendungen anpassen.
Betrachten Sie beispielsweise das folgende Szenario. Es gibt mehrere Cluster, die miteinander kommunizieren müssen. Sie möchten jedoch nur einem bestimmten Teilsatz von Clustern eingehenden SSH-Zugriff auf die Primär-Instance gewähren. Hierzu können Sie für die Cluster den gleichen Satz von verwalteten Sicherheitsgruppen verwenden. Anschließend erstellen Sie zusätzliche Sicherheitsgruppen, die eingehenden SSH-Zugriff von vertrauenswürdigen Clients zulassen, und geben die zusätzlichen Sicherheitsgruppen für die Primär-Instance für jeden Cluster in der Untergruppe an.
Sie können bis zu 15 zusätzliche Sicherheitsgruppen für die primäre Instance, 15 für Core- und Task-Instances und 15 für den Servicezugriff (in privaten Subnetzen) anwenden. Wenn notwendig, können Sie dieselben zusätzlichen Sicherheitsgruppen für Primär-Instances, Core- und Aufgaben-Instances und den Servicezugriff angeben. Die maximale Anzahl von Sicherheitsgruppen und -regeln in Ihrem Konto unterliegt Kontolimits. Weitere Informationen finden Sie unter [Sicherheitsgruppenlimits](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html#vpc-limits-security-groups) im *Amazon-VPC-Benutzerhandbuch*.
# Angeben von Amazon-EMR-verwalteten und zusätzlichen Sicherheitsgruppen
Sie können Sicherheitsgruppen mithilfe der AWS-Managementkonsole AWS CLI, der oder der Amazon EMR-API angeben. Wenn Sie keine Sicherheitsgruppen angeben, erstellt Amazon EMR Standardsicherheitsgruppen. Die Angabe zusätzlicher Sicherheitsgruppen ist optional. Sie können Primär-Instances, Core- und Aufgaben-Instances und dem Servicezugriff (nur private Subnetze) zusätzliche Sicherheitsgruppen zuweisen.
------
#### [ Console ]
**Um Sicherheitsgruppen mit der Konsole anzugeben**
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon EMR-Konsole unter [https://console.aws.amazon.com/emr](https://console.aws.amazon.com/emr).
1. Wählen Sie im linken Navigationsbereich unter **EMR in EC2** die Option **Cluster** und dann **Cluster erstellen** aus.
1. Wählen Sie auf der Registerkarte Eigenschaften unter **Netzwerk** den Pfeil neben **EC2-Sicherheitsgruppen (Firewall)** aus, um diesen Abschnitt zu erweitern. Unter **Primärknoten** und **Kern- und Aufgabenknoten** sind standardmäßig die von Amazon EMR verwalteten Standardsicherheitsgruppen ausgewählt. Wenn Sie ein privates Subnetz verwenden, haben Sie auch die Möglichkeit, eine Sicherheitsgruppe für den **Servicezugriff** auszuwählen.
1. Um Ihre von Amazon EMR verwaltete Sicherheitsgruppe zu ändern, verwenden Sie das Dropdownmenü **Sicherheitsgruppen auswählen**, um eine andere Option aus der Optionsliste der **Von Amazon EMR verwalteten Sicherheitsgruppen** auszuwählen. Sie haben eine von Amazon EMR verwaltete Sicherheitsgruppe sowohl für den **Primärknoten** als auch für den **Core- und Aufgabenknoten**.
1. Um benutzerdefinierte Sicherheitsgruppen hinzuzufügen, verwenden **Sie dasselbe Dropdownmenü Sicherheitsgruppen** auswählen, um bis zu vier benutzerdefinierte Sicherheitsgruppen aus der Optionsliste **Benutzerdefinierte Sicherheitsgruppen** auszuwählen. Sie können bis zu vier benutzerdefinierte Sicherheitsgruppen sowohl für den **Primärknoten** als auch für den **Kern- und Aufgabenknoten** einrichten.
1. Wählen Sie alle anderen Optionen aus, die für Ihren Cluster gelten.
1. Um Ihren Cluster jetzt zu starten, wählen Sie **Cluster erstellen** aus.
------
## Angeben von Sicherheitsgruppen mit dem AWS CLI
Um Sicherheitsgruppen mit dem zu spezifizieren, verwenden AWS CLI Sie den `create-cluster` Befehl mit den folgenden Parametern der `--ec2-attributes` Option:
| Parameter | Description |
| --- | --- |
| `EmrManagedPrimarySecurityGroup` | Verwenden Sie diesen Parameter, um eine benutzerdefinierte verwaltete Sicherheitsgruppe für die Primär-Instance anzugeben. Wenn dieser Parameter angegeben wird, muss auch `EmrManagedCoreSecurityGroup` angegeben werden. Für Cluster in privaten Subnetzen muss auch `ServiceAccessSecurityGroup` angegeben werden. |
| `EmrManagedCoreSecurityGroup` | Verwenden Sie diesen Parameter, um eine benutzerdefinierte verwaltete Sicherheitsgruppe für Core- und Aufgaben-Instances anzugeben. Wenn dieser Parameter angegeben wird, muss auch `EmrManagedPrimarySecurityGroup` angegeben werden. Für Cluster in privaten Subnetzen muss auch `ServiceAccessSecurityGroup` angegeben werden. |
| `ServiceAccessSecurityGroup` | Verwenden Sie diesen Parameter, um eine benutzerdefinierte verwaltete Sicherheitsgruppe für den Servicezugriff anzugeben. Dies gilt nur für Cluster in privaten Subnetzen. Die Sicherheitsgruppe, als die Sie angeben, `ServiceAccessSecurityGroup` sollte nicht für andere Zwecke verwendet werden und sollte auch für Amazon EMR reserviert werden. Wenn dieser Parameter angegeben wird, muss auch `EmrManagedPrimarySecurityGroup` angegeben werden. |
| `AdditionalPrimarySecurityGroups` | Verwenden Sie diesen Parameter, um bis zu vier zusätzliche verwaltete Sicherheitsgruppen für die Primär-Instance anzugeben. |
| `AdditionalCoreSecurityGroups` | Verwenden Sie diesen Parameter, um bis zu vier zusätzliche verwaltete Sicherheitsgruppen für die Core- und Aufgaben-Instances anzugeben. |
**Example – spezifizieren Sie benutzerdefinierte, von Amazon EMR verwaltete Sicherheitsgruppen und zusätzliche Sicherheitsgruppen**
Im folgenden Beispiel werden benutzerdefinierte Amazon-EMR-verwaltete Sicherheitsgruppen für einen Cluster in einem privaten Subnetz, mehrere zusätzliche Sicherheitsgruppen für die Master-Instance und eine einzelne zusätzliche Sicherheitsgruppe für Core- und Aufgaben-Instances angegeben.
Linux-Zeilenfortsetzungszeichen (\$1) sind aus Gründen der Lesbarkeit enthalten. Sie können entfernt oder in Linux-Befehlen verwendet werden. Entfernen Sie sie unter Windows oder ersetzen Sie sie durch ein Caret-Zeichen (^).
```
1. aws emr create-cluster --name "ClusterCustomManagedAndAdditionalSGs" \
2. --release-label emr-emr-7.12.0 --applications Name=Hue Name=Hive \
3. Name=Pig --use-default-roles --ec2-attributes \
4. SubnetIds=subnet-xxxxxxxxxxxx,KeyName=myKey,\
5. ServiceAccessSecurityGroup=sg-xxxxxxxxxxxx,\
6. EmrManagedPrimarySecurityGroup=sg-xxxxxxxxxxxx,\
7. EmrManagedCoreSecurityGroup=sg-xxxxxxxxxxx,\
8. AdditionalPrimarySecurityGroups=['sg-xxxxxxxxxxx',\
9. 'sg-xxxxxxxxxxx','sg-xxxxxxxxxx'],\
10. AdditionalCoreSecurityGroups=sg-xxxxxxxxxxx \
11. --instance-type m5.xlarge
```
Weitere Informationen finden Sie unter [create-cluster](https://docs.aws.amazon.com/cli/latest/reference/emr/create-cluster.html) in der *AWS CLI -Befehlsreferenz*.
# Angeben von EC2-Sicherheitsgruppen für EMR Notebooks
Wenn Sie ein EMR Notebook erstellen, wird der Netzwerkdatenverkehr zwischen dem EMR Notebook und dem Amazon-EMR-Cluster mithilfe von zwei Sicherheitsgruppen gesteuert, wenn Notebook-verwendet wird. Die Standard-Sicherheitsgruppen verfügen über Mindestregeln, die nur Netzwerkdatenverkehr zwischen dem EMR-Notebooks-Service und den Clustern zulassen, an die die Notebooks angefügt sind.
Ein EMR-Notebook verwendet [Apache Livy](https://livy.incubator.apache.org/), um über einen Proxy über den TCP-Port 18888 mit dem Cluster zu kommunizieren. Indem Sie benutzerdefinierte Sicherheitsgruppen mit an Ihre Umgebung angepassten Regeln erstellen, können Sie den Netzwerkdatenverkehr so einschränken, dass nur ein Teil der Notebooks Code innerhalb des Notebook-Editors auf bestimmten Clustern ausführen kann. Der Cluster verwendet Ihre benutzerdefinierte Sicherheit zusätzlich zu den Standardsicherheitsgruppen für den Cluster. Weitere Informationen finden Sie unter [Steuerung des Netzwerkverkehrs mit Sicherheitsgruppen](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-security-groups.html) im *Verwaltungshandbuch für Amazon EMR* und [Angeben von EC2-Sicherheitsgruppen für EMR Notebooks](#emr-managed-notebooks-security-groups).
## EC2-Standard-Sicherheitsgruppe für die primäre Instance
Zusätzlich zu den Sicherheitsgruppen des Clusters für die primären Instance ist die EC2-Standard-Sicherheitsgruppe für die primären-Instance der Master-Instance zugeordnet.
Gruppenname: **ElasticMapReduceEditors-Livy**
**Regeln**
+ Eingehend
Zulassen von TCP Port 18888 von allen Ressourcen in der EC2-Standard-Sicherheitsgruppe für EMR Notebooks
+ Ausgehend
Keine
## Standard-EC2-Sicherheitsgruppe für EMR Notebooks
Die EC2-Standard-Sicherheitsgruppe für ist mit dem EMR- Notebook-Editor für alle EMR Notebooks verknüpft, denen sie zugewiesen ist.
**Gruppenname: -Editor ElasticMapReduceEditors**
**Regeln**
+ Eingehend
Keine
+ Ausgehend
Lassen Sie TCP Port 18888 auf alle Ressourcen in der EC2-Standard-Sicherheitsgruppe für EMR Notebooks zu.
## Benutzerdefinierte EC2-Sicherheitsgruppe für EMR Notebooks beim Zuordnen von Notebooks zu Git-Repositorys
Um ein Git-Repository mit Ihrem Notebook verknüpfen zu können, muss die Sicherheitsgruppe für das EMR Notebook eine Regel für ausgehenden Datenverkehr enthalten, damit das Notebook Datenverkehr an das Internet weiterleiten kann. Es wird empfohlen, zu diesem Zweck eine neue Sicherheitsgruppe zu erstellen. Bei der Aktualisierung der Standard-Sicherheitsgruppe **ElasticMapReduceEditors-Editor** gelten möglicherweise dieselben Regeln für ausgehende Nachrichten auch für andere Notebooks, die zu dieser Sicherheitsgruppe gehören.
**Regeln**
+ Eingehend
Keine
+ Ausgehend
Erlauben Sie dem Notebook, Datenverkehr über den Cluster an das Internet zu leiten, wie im folgenden Beispiel veranschaulicht. Der Wert 0.0.0.0/0 wird für Beispielzwecke verwendet. Sie können diese Regel ändern, um die IP-Adressen für Ihre Git-basierten Repositorys anzugeben.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/emr-managed-notebooks-security-groups.html)
# Verwenden von Amazon EMR Block Public Access
Amazon EMR *Block Public Access (BPA)* verhindert, dass Sie einen Cluster in einem öffentlichen Subnetz starten, wenn der Cluster über eine Sicherheitskonfiguration verfügt, die eingehenden Datenverkehr von öffentlichen IP-Adressen an einem Port zulässt.
**Wichtig**
*Den öffentlichen Zugriff blockieren* ist standardmäßig aktiviert. Um den Kontoschutz zu erhöhen, empfehlen wir, ihn aktiviert zu lassen.
## Grundlegendes zum Blockieren des öffentlichen Zugriffs
Sie können die Konfiguration *Block Public Access* auf Kontoebene verwenden, um den öffentlichen Netzwerkzugriff auf Amazon-EMR-Cluster zentral zu verwalten.
Wenn ein Benutzer von Ihnen einen Cluster AWS-Konto startet, überprüft Amazon EMR die Portregeln in der Sicherheitsgruppe für den Cluster und vergleicht sie mit Ihren Regeln für eingehenden Datenverkehr. Wenn die Sicherheitsgruppe über eine Regel für eingehenden Datenverkehr verfügt, die Ports zu den öffentlichen IP-Adressen IPv4 0.0.0.0/0 oder IPv6 : :/0 öffnet, und diese Ports nicht als Ausnahmen für Ihr Konto angegeben sind, lässt Amazon EMR den Benutzer den Cluster nicht erstellen.
Wenn ein Benutzer die Sicherheitsgruppenregeln für einen laufenden Cluster in einem öffentlichen Subnetz so ändert, dass er über eine Regel für den öffentlichen Zugriff verfügt, die gegen die BPA-Konfiguration für Ihr Konto verstößt, widerruft Amazon EMR die neue Regel, sofern es dazu berechtigt ist. Wenn Amazon EMR nicht berechtigt ist, die Regel zu widerrufen, wird im AWS Health -Dashboard ein Ereignis erstellt, das den Verstoß beschreibt. Informationen dazu, wie Sie Amazon EMR die Berechtigung zum Widerrufen der Regel erteilen, finden Sie unter [Amazon EMR so konfigurieren, dass Sicherheitsgruppenregeln aufgehoben werden](#revoke-block-public-access).
Den öffentlichen Zugriff blockieren ist standardmäßig für alle Cluster in jedem AWS-Region für Ihr AWS-Konto aktiviert. BPA gilt für den gesamten Lebenszyklus eines Clusters, gilt jedoch nicht für Cluster, die Sie in privaten Subnetzen erstellen. Sie können Ausnahmen von der BPA-Regel konfigurieren. Port 22 ist standardmäßig eine Ausnahme. Weitere Informationen zur Einstellung finden Sie unter [Konfigurieren von Block Public Access](#configure-block-public-access).
## Konfigurieren von Block Public Access
Sie können die Sicherheitsgruppen und die Konfiguration zum Sperren des öffentlichen Zugriffs in Ihren Konten jederzeit aktualisieren.
Sie können die Einstellungen für den öffentlichen Zugriff (Block Public Access, BPA) mit der AWS-Managementkonsole, der AWS Command Line Interface (AWS CLI) und der Amazon EMR-API ein- und ausschalten. Die Einstellungen gelten für Ihr gesamtes Konto auf einer Region-by-Region bestimmten Basis. Um die Clustersicherheit aufrechtzuerhalten, wird die Verwendung von BPA empfohlen.
------
#### [ Console ]
**Um den öffentlichen Zugriff blockieren mit der Konsole zu konfigurieren**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie dann die Amazon EMR-Konsole unter [https://console.aws.amazon.com/emr](https://console.aws.amazon.com/emr).
1. Wählen Sie in der oberen Navigationsleiste die **Region** aus, die Sie konfigurieren möchten, sofern sie nicht bereits ausgewählt ist.
1. Wählen Sie im linken Navigationsbereich unter **EMR in EC2** die Option **Block Public Access** aus.
1. Führen Sie unter **Block public access settings ** (Einstellungen für die Sperrung des öffentlichen Zugriffs) die folgenden Schritte aus.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/emr-block-public-access.html)
------
#### [ AWS CLI ]
**Um den öffentlichen Zugriff sperren zu konfigurieren, verwenden Sie den AWS CLI**
+ Verwenden Sie den `aws emr put-block-public-access-configuration`-Befehl, um Block Public Access zu konfigurieren, wie in den folgenden Beispielen gezeigt.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/emr-block-public-access.html)
------
## Amazon EMR so konfigurieren, dass Sicherheitsgruppenregeln aufgehoben werden
Amazon EMR benötigt die Erlaubnis, Sicherheitsgruppenregeln zu widerrufen und Ihre Konfiguration für die Blockierung des öffentlichen Zugriffs einzuhalten. Sie können einen der folgenden Ansätze verwenden, um Amazon EMR die erforderliche Genehmigung zu erteilen:
+ **(Empfohlen)** Fügen Sie der Servicerolle die `AmazonEMRServicePolicy_v2`-verwaltete Richtlinie hinzu. Weitere Informationen finden Sie unter [Servicerolle für Amazon EMR (EMR-Rolle)](emr-iam-role.md).
+ Erstellen Sie eine neue Inline-Richtlinie, die die `ec2:RevokeSecurityGroupIngress`-Aktion für Sicherheitsgruppen ermöglicht. Weitere Informationen zum Ändern einer Rollenberechtigungsrichtlinie finden Sie unter **Ändern einer Rollenberechtigungsrichtlinie** mit der [IAM-Konsole](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-managingrole-editing-console.html#roles-modify_permissions-policy), der [AWS -API](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-managingrole-editing-api.html#roles-modify_permissions-policy-api) und [AWS CLI](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-managingrole-editing-cli.html#roles-modify_permissions-policy-cli) im *IAM-Benutzerhandbuch*.
## Beheben von Verletzungen des Blockieren des öffentlichen Zugriffs
Wenn ein Verstoß gegen die Sperrung des öffentlichen Zugriffs auftritt, können Sie ihn mit einer der folgenden Maßnahmen beheben:
+ Wenn Sie auf eine Webschnittstelle Ihres Clusters zugreifen möchten, verwenden Sie eine der unter [Anzeigen von auf Amazon-EMR-Clustern gehosteten Webschnittstellen](emr-web-interfaces.md) beschriebenen Optionen, um über SSH (Port 22) auf die Schnittstelle zuzugreifen.
+ Um den Datenverkehr zum Cluster von bestimmten IP-Adressen statt von der öffentlichen IP-Adresse aus zuzulassen, fügen Sie eine Sicherheitsgruppenregel hinzu. Weitere Informationen finden Sie unter [Hinzufügen von Regeln zur Sicherheitsgruppe](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/working-with-security-groups.html#adding-security-group-rule) im *Amazon-EC2-Benutzerhandbuch*.
+ **(Nicht empfohlen)** Sie können Amazon-EMR-BPA-Ausnahmen so konfigurieren, dass sie den gewünschten Port oder Portbereich enthalten. Wenn Sie eine BPA-Ausnahme angeben, gehen Sie mit einem ungeschützten Port ein Risiko ein. Wenn Sie beabsichtigen, eine Ausnahme anzugeben, sollten Sie die Ausnahme entfernen, sobald sie nicht mehr benötigt wird. Weitere Informationen finden Sie unter [Konfigurieren von Block Public Access](#configure-block-public-access).
## Identifizieren Sie Cluster, die Sicherheitsgruppenregeln zugeordnet sind
Möglicherweise müssen Sie alle Cluster identifizieren, die einer bestimmten Sicherheitsgruppenregel zugeordnet sind, oder die Sicherheitsgruppenregel für einen bestimmten Cluster finden.
+ Wenn Sie die Sicherheitsgruppe kennen, können Sie die zugehörigen Cluster identifizieren, wenn Sie die Netzwerkschnittstellen für die Sicherheitsgruppe finden. Weitere Informationen finden Sie unter [Wie finde ich die Ressourcen, die einer Amazon-EC2-Sicherheitsgruppe zugeordnet sind?](https://forums.aws.amazon.com/knowledge-center/ec2-find-security-group-resources) in AWS re:Post. Die Amazon EC2-Instances, die an diese Netzwerkschnittstellen angeschlossen sind, werden mit der ID des Clusters gekennzeichnet, zu dem sie gehören.
+ Wenn Sie die Sicherheitsgruppen für einen bekannten Cluster suchen möchten, folgen Sie den Schritten unter [Status und Details des Amazon EMR-Clusters anzeigen](emr-manage-view-clusters.md). Sie finden die Sicherheitsgruppen für den Cluster im Bereich **Netzwerk und Sicherheit** in der Konsole oder im `Ec2InstanceAttributes`-Feld unter AWS CLI.
# Compliance-Validierung für Amazon EMR
Externe Prüfer bewerten die Sicherheit und Konformität von Amazon EMR im Rahmen mehrerer AWS Compliance-Programme. Hierzu zählen unter anderem SOC, PCI, FedRAMP und HIPAA.
Eine Liste der AWS Services im Rahmen bestimmter Compliance-Programme finden Sie unter [AWS Services im Umfang der einzelnen Compliance-Programme](https://aws.amazon.com/compliance/services-in-scope/). Allgemeine Informationen finden Sie unter [AWS -Compliance-Programme](https://aws.amazon.com/compliance/programs/).
Sie können Prüfberichte von Drittanbietern unter herunterladen AWS Artifact. Weitere Informationen finden Sie unter [Berichte herunterladen in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html).
Ihre Compliance-Verantwortung bei Verwendung von Amazon EMR hängt von der Vertraulichkeit der Daten, den Compliance-Zielen des Unternehmens und den geltenden Gesetzen und Vorschriften ab. Falls Ihre Nutzung von Amazon EMR der Einhaltung von Standards wie HIPAA, PCI oder FedRAMP unterliegt, bietet Ihnen folgende Ressourcen: AWS
+ [Schnellstartanleitungen zu Sicherheit und Compliance](https://aws.amazon.com/quickstart/?awsf.quickstart-homepage-filter=categories%23security-identity-compliance) — In diesen Bereitstellungsleitfäden werden architektonische Überlegungen erörtert und Schritte für die Implementierung von sicherheits- und Compliance-orientierten Basisumgebungen beschrieben. AWS
+ Whitepaper „[Architecting for HIPAA Security and Compliance“ — In diesem Whitepaper](https://docs.aws.amazon.com/whitepapers/latest/architecting-hipaa-security-and-compliance-on-aws/architecting-hipaa-security-and-compliance-on-aws.html) wird beschrieben, wie Unternehmen HIPAA-konforme Anwendungen entwickeln können. AWS
+ [AWS Ressourcen zur Einhaltung](https://aws.amazon.com/compliance/resources/) von Vorschriften — Diese Sammlung von Arbeitsmappen und Leitfäden könnte für Ihre Branche und Ihren Standort gelten.
+ [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html)— Dieser AWS Service bewertet, wie gut Ihre Ressourcenkonfigurationen den internen Praktiken, Branchenrichtlinien und Vorschriften entsprechen.
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)— Dieser AWS Service bietet einen umfassenden Überblick über Ihren Sicherheitsstatus und hilft Ihnen AWS , die Einhaltung der Sicherheitsstandards und bewährten Verfahren der Sicherheitsbranche zu überprüfen.
# Ausfallsicherheit bei Amazon EMR
Die AWS globale Infrastruktur basiert auf AWS Regionen und Availability Zones. AWS Regionen bieten mehrere physisch getrennte und isolierte Availability Zones, die über Netzwerke mit niedriger Latenz, hohem Durchsatz und hoher Redundanz miteinander verbunden sind. Mithilfe von Availability Zones können Sie Anwendungen und Datenbanken erstellen und ausführen, die automatisch Failover zwischen Availability Zones ausführen, ohne dass es zu Unterbrechungen kommt. Availability Zones sind besser hoch verfügbar, fehlertoleranter und skalierbarer als herkömmliche Infrastrukturen mit einem oder mehreren Rechenzentren.
Weitere Informationen zu AWS Regionen und Availability Zones finden Sie unter [AWS Globale](https://aws.amazon.com/about-aws/global-infrastructure/) Infrastruktur.
Zusätzlich zur AWS globalen Infrastruktur bietet Amazon EMR mehrere Funktionen, die Sie bei der Unterstützung Ihrer Datenausfallsicherheit und Ihrer Backup-Anforderungen unterstützen.
+ **Integration in Amazon S3 über EMRFS**
+ **Support für mehrere Master-Knoten**
# Infrastruktursicherheit in Amazon EMR
Als verwalteter Service ist Amazon EMR durch AWS globale Netzwerksicherheit geschützt. Informationen zu AWS Sicherheitsdiensten und zum AWS Schutz der Infrastruktur finden Sie unter [AWS Cloud-Sicherheit](https://aws.amazon.com/security/). Informationen zum Entwerfen Ihrer AWS Umgebung unter Verwendung der bewährten Methoden für die Infrastruktursicherheit finden Sie unter [Infrastructure Protection](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) in *Security Pillar AWS Well‐Architected Framework*.
Sie verwenden AWS veröffentlichte API-Aufrufe, um über das Netzwerk auf Amazon EMR zuzugreifen. Kunden müssen Folgendes unterstützen:
+ Transport Layer Security (TLS). Wir benötigen TLS 1.2 und empfehlen TLS 1.3.
+ Verschlüsselungs-Suiten mit Perfect Forward Secrecy (PFS) wie DHE (Ephemeral Diffie-Hellman) oder ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). Die meisten modernen Systeme wie Java 7 und höher unterstützen diese Modi.
**Topics**
+ [Herstellen einer Verbindung mit Amazon EMR über einen Schnittstellen-VPC-Endpunkt](interface-vpc-endpoint.md)
# Herstellen einer Verbindung mit Amazon EMR über einen Schnittstellen-VPC-Endpunkt
Sie können eine direkte Verbindung zu Amazon EMR herstellen, indem Sie einen [VPC-Endpunkt (AWS PrivateLink)](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpce-interface.html) in Ihrer Virtual Private Cloud (VPC) verwenden, anstatt eine Verbindung über das Internet herzustellen. Wenn Sie einen VPC-Endpunkt mit Schnittstelle verwenden, erfolgt die Kommunikation zwischen Ihrer VPC und Amazon EMR vollständig innerhalb des Netzwerks. AWS Jeder VPC-Endpunkt wird durch eine oder mehrere [Elastic Network-Schnittstellen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) (ENIs) mit privaten IP-Adressen in Ihren VPC-Subnetzen repräsentiert.
Der VPC-Endpunkt der Schnittstelle verbindet Ihre VPC ohne Internet-Gateway, NAT-Gerät, VPN-Verbindung oder Verbindung direkt mit Amazon EMR. Direct Connect Die Instances in Ihrer VPC benötigen für die Kommunikation mit der API von Amazon EMR keine öffentlichen IP-Adressen.
Um Amazon EMR über Ihre VPC zu verwenden, müssen Sie für die Verbindung eine Instance innerhalb Ihrer VPC verwenden oder Ihr privates Netzwerk mit Ihrer VPC verbinden. Dies erreichen Sie mithilfe eines Amazon Virtual Private Network (VPN) oder mit Direct Connect. Informationen zu Amazon VPN finden Sie unter [VPN-Verbindungen](https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html) im *Benutzerhandbuch für Amazon Virtual Private Cloud*. *Weitere Informationen dazu AWS Direct Connect finden Sie unter [Verbindung erstellen](https://docs.aws.amazon.com/directconnect/latest/UserGuide/create-connection.html) im Direct Connect Benutzerhandbuch.*
Sie können einen VPC-Schnittstellen-Endpunkt erstellen, um mithilfe der AWS Konsole oder der Befehle AWS Command Line Interface (AWS CLI) eine Verbindung zu Amazon EMR herzustellen. Weitere Informationen finden Sie unter [Erstellen eines Schnittstellenendpunkts](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpce-interface.html#create-interface-endpoint).
Wenn Sie nach dem Erstellen eines Schnittstellen-VPC-Endpunkts private DNS-Host-Namen für den Endpunkt aktivieren, wird der Standardendpunkt von Amazon EMR in den VPC-Endpunkt aufgelöst. Der Service-Standardname für den Endpunkt für Amazon EMR hat das folgende Format.
```
elasticmapreduce.Region.amazonaws.com
```
Wenn Sie keine privaten DNS-Hostnamen aktiviert haben, stellt Amazon VPC einen DNS-Endpunktnamen bereit, den Sie im folgenden Format verwenden können.
```
VPC_Endpoint_ID.elasticmapreduce.Region.vpce.amazonaws.com
```
Weitere Informationen finden Sie unter [Schnittstellen-VPC-Endpunkte (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html) im *Amazon-VPC-Benutzerhandbuch*.
Amazon EMR unterstützt Aufrufe aller [API-Aktionen](https://docs.aws.amazon.com/emr/latest/APIReference/API_Operations.html) innerhalb Ihrer VPC.
Sie können VPC-Endpunktrichtlinien an einen VPC-Endpunkt anfügen, um den Zugriff für IAM-Prinzipale zu steuern. Sie können einem VPC-Endpunkt auch Sicherheitsgruppen zuordnen, um den eingehenden und ausgehenden Zugriff basierend auf Ursprung und Ziel des Netzwerkdatenverkehrs zu steuern, z. B. mit einem IP-Adressbereich. Weitere Informationen finden Sie unter [Steuern des Zugriffs auf Services mit VPC-Endpunkten](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html).
## Eine VPC-Endpunktrichtlinie für Amazon EMR erstellen
Sie können eine Richtlinie für Amazon-VPC-Endpunkte für Amazon EMR erstellen, in der Sie Folgendes angeben:
+ Prinzipal, der Aktionen ausführen/nicht ausführen kann
+ Aktionen, die ausgeführt werden können
+ Ressourcen, für die Aktionen ausgeführt werden können
Weitere Informationen finden Sie unter [Steuerung des Zugriffs auf Services mit VPC-Endpunkten](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html) im *Amazon-VPC-Benutzerhandbuch*.
**Example — VPC-Endpunktrichtlinie, um jeglichen Zugriff von einem bestimmten AWS Konto aus zu verweigern**
Die folgende VPC-Endpunktrichtlinie verweigert dem AWS Konto *123456789012* jeglichen Zugriff auf Ressourcen, die den Endpunkt verwenden.
```
{
"Statement": [
{
"Action": "*",
"Effect": "Allow",
"Resource": "*",
"Principal": "*"
},
{
"Action": "*",
"Effect": "Deny",
"Resource": "*",
"Principal": {
"AWS": [
"123456789012"
]
}
}
]
}
```
**Example – VPC-Endpunktrichtlinie zum Gewähren des VPC-Zugriffs auf einen angegebenen IAM-Prinzipal (Benutzer)**
Die folgende VPC-Endpunktrichtlinie ermöglicht vollen Zugriff nur für das AWS Konto *123456789012* eines Benutzers*lijuan*. Allen anderen IAM-Prinzipalen wird der Zugriff über den Endpunkt verweigert.
```
{
"Statement": [
{
"Action": "*",
"Effect": "Allow",
"Resource": "*",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:user/lijuan"
]
}
}]
}
```
**Example – VPC-Endpunktrichtlinie zum Erlauben von EMR-Leseoperationen**
Die folgende VPC-Endpunktrichtlinie erlaubt nur AWS Konten*123456789012*, die angegebenen Amazon EMR-Aktionen durchzuführen.
Die angegebenen Aktionen stellen das Äquivalent von schreibgeschütztem Zugriff für Amazon EMR dar. Alle anderen Aktionen in der VPC werden dem angegebenen Konto verweigert. Allen anderen Konten wird der Zugriff verweigert. Eine Liste der Aktionen in Amazon EMR finden Sie unter [Aktionen, Ressourcen und Bedingungsschlüssel für Amazon EMR](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonelasticmapreduce.html).
```
{
"Statement": [
{
"Action": [
"elasticmapreduce:DescribeSecurityConfiguration",
"elasticmapreduce:GetBlockPublicAccessConfiguration",
"elasticmapreduce:ListBootstrapActions",
"elasticmapreduce:ViewEventsFromAllClustersInConsole",
"elasticmapreduce:ListSteps",
"elasticmapreduce:ListInstanceFleets",
"elasticmapreduce:DescribeCluster",
"elasticmapreduce:ListInstanceGroups",
"elasticmapreduce:DescribeStep",
"elasticmapreduce:ListInstances",
"elasticmapreduce:ListSecurityConfigurations",
"elasticmapreduce:DescribeEditor",
"elasticmapreduce:ListClusters",
"elasticmapreduce:ListEditors"
],
"Effect": "Allow",
"Resource": "*",
"Principal": {
"AWS": [
"123456789012"
]
}
}
]
}
```
**Example – VPC-Endpunktrichtlinie, die den Zugriff auf einen angegebenen Cluster verweigert**
Die folgende VPC-Endpunktrichtlinie ermöglicht vollen Zugriff für alle Konten und Principals, verweigert dem AWS Konto *123456789012* jedoch jeglichen Zugriff auf Aktionen, die auf dem Amazon EMR-Cluster mit Cluster-ID ausgeführt werden. *j-A1B2CD34EF5G* Andere Amazon-EMR-Aktionen, die keine Berechtigungen auf Ressourcenebene für Cluster unterstützen, sind weiterhin zulässig. Eine Liste der Amazon-EMR-Aktionen und die entsprechenden Ressourcentypen finden Sie unter [Aktionen, Ressourcen und Bedingungsschlüssel für Amazon EMR](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonelasticmapreduce.html).
```
{
"Statement": [
{
"Action": "*",
"Effect": "Allow",
"Resource": "*",
"Principal": "*"
},
{
"Action": "*",
"Effect": "Deny",
"Resource": "arn:aws:elasticmapreduce:us-west-2:123456789012:cluster/j-A1B2CD34EF5G",
"Principal": {
"AWS": [
"123456789012"
]
}
}
]
}
```