Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Aktivieren Sie IAM-Rollen für den EKS-Cluster In den folgenden Themen werden die Optionen für die Aktivierung von IAM-Rollen detailliert beschrieben. **Topics** + [ # Option 1: Aktivieren Sie EKS Pod Identity auf dem EKS-Cluster ](setting-up-enable-IAM.md) + [ # Option 2: Aktivieren Sie IAM-Rollen für Service Accounts (IRSA) auf dem EKS-Cluster ](setting-up-enable-IAM-service-accounts.md) # Option 1: Aktivieren Sie EKS Pod Identity auf dem EKS-Cluster Amazon-EKS-Pod-Identity-Zuordnungen bieten die Möglichkeit, Anmeldeinformationen für Ihre Anwendungen zu verwalten, ähnlich wie Amazon-EC2-Instance-Profile Anmeldeinformationen für Amazon-EC2-Instances bereitstellen. Amazon EKS Pod Identity bietet Anmeldeinformationen für Ihre Workloads mit einer zusätzlichen EKS-Auth-API und einem Agent-Pod, der auf jedem Knoten ausgeführt wird. Amazon EMR on EKS unterstützt seit der Version emr-7.3.0 die EKS-Pod-Identität für das Einreichungsmodell. StartJobRun Weitere Informationen zu EKS-Pod-Identitäten finden Sie unter Grundlegendes zur [Funktionsweise](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-how-it-works.html) von EKS Pod Identity. ## Warum EKS Pod Identities? Im Rahmen des EMR-Setups muss die Job Execution Role Vertrauensgrenzen zwischen einer IAM-Rolle und Dienstkonten in einem bestimmten Namespace (von virtuellen EMR-Clustern) einrichten. Mit IRSA wurde dies durch die Aktualisierung der Vertrauensrichtlinie der EMR Job Execution Role erreicht. Aufgrund der festen Begrenzung der Länge der IAM-Vertrauensrichtlinie auf 4096 Zeichen bestand jedoch die Einschränkung, eine einzelne IAM-Rolle für die Ausführung von Job auf maximal zwölf (12) EKS-Clustern gemeinsam zu nutzen. Da EMR Pod-Identitäten unterstützt, wird die Vertrauensgrenze zwischen IAM-Rollen und Dienstkonten nun vom EKS-Team über die Verknüpfung von EKS Pod Identities verwaltet. APIs **Anmerkung** Die Sicherheitsgrenze für die EKS-Pod-Identität liegt immer noch auf der Ebene der Dienstkonten, nicht auf der Pod-Ebene. ## Überlegungen zur Pod-Identität Informationen zu den Einschränkungen der Pod-Identität finden Sie unter [Überlegungen zur EKS Pod-Identität](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html#pod-id-considerations). ## Bereiten Sie die EKS-Pod-Identität im EKS-Cluster vor ### Überprüfen Sie, ob die erforderliche Berechtigung in vorhanden ist NodeInstanceRole Die Knotenrolle `NodeInstanceRole` benötigt eine Berechtigung, damit der Agent die `AssumeRoleForPodIdentity` Aktion in der EKS Auth API ausführen kann. Sie können dem [Amazon EKSWorkerNodePolicy, das im Amazon](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/security-iam-awsmanpol.html#security-iam-awsmanpol-amazoneksworkernodepolicy) EKS-Benutzerhandbuch definiert ist, Folgendes hinzufügen oder eine benutzerdefinierte Richtlinie verwenden. Wenn Ihr EKS-Cluster mit einer eksctl-Version höher als **0.181.0** erstellt wurde, wird Amazon EKSWorkerNodePolicy, einschließlich der erforderlichen `AssumeRoleForPodIdentity` Berechtigungen, automatisch an die Knotenrolle angehängt. Wenn die Berechtigung nicht vorhanden ist, fügen Sie Amazon manuell die folgende Berechtigung hinzu, mit der Sie eine Rolle für EKSWorker NodePolicy die Pod-Identität übernehmen können. Diese Berechtigung wird vom EKS-Pod-Identity-Agenten benötigt, um Anmeldeinformationen für Pods abzurufen. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "eks-auth:AssumeRoleForPodIdentity" ], "Resource": [ "*" ], "Sid": "AllowEKSAUTHAssumeroleforpodidentity" } ] } ``` ------ ### Erstellen Sie das EKS-Pod-Identity-Agent-Add-On Verwenden Sie den folgenden Befehl, um das EKS Pod Identity Agent-Add-On mit der neuesten Version zu erstellen: ``` aws eks create-addon --cluster-name cluster-name --addon-name eks-pod-identity-agent kubectl get pods -n kube-system | grep 'eks-pod-identity-agent' ``` Gehen Sie wie folgt vor, um das EKS Pod Identity Agent-Add-On von der Amazon EKS-Konsole aus zu erstellen: 1. Öffnen Sie die Amazon EKS-Konsole: [Amazon EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters). 1. Wählen Sie im linken Navigationsbereich **Cluster** aus. Wählen Sie anschließend den Namen des Clusters aus, für den Sie das Add-on „EKS Pod Identity Agent“ konfigurieren möchten. 1. Wählen Sie die Registerkarte **Add-ons**. 1. Wählen Sie **Weitere Add-Ons erhalten**. 1. Wählen Sie das Kästchen oben rechts im Add-on-Bereich für EKS Pod Identity Agent aus und gehen Sie dann auf **Bearbeiten**. 1. Wählen Sie auf der Seite **„Ausgewählte Add-Ons konfigurieren**“ eine beliebige Version in der Dropdownliste **Version** aus. 1. (Optional) Erweitern Sie **Optionale Konfigurationseinstellungen**, um eine zusätzliche Konfiguration einzugeben. Sie können beispielsweise einen alternativen Speicherort für das Container-Image und `ImagePullSecrets` angeben. Das JSON-Schema mit den akzeptierten Schlüsseln wird im **Add-On-Konfigurationsschema** angezeigt. Geben Sie die Konfigurationsschlüssel und Werte in das Feld **Konfigurationswerte** ein 1. Wählen Sie **Weiter** aus. 1. Vergewissern Sie sich über die CLI, dass die Agent-Pods auf Ihrem Cluster ausgeführt werden. `kubectl get pods -n kube-system | grep 'eks-pod-identity-agent'` Eine Beispielausgabe sieht wie folgt aus: ``` NAME READY STATUS RESTARTS AGE eks-pod-identity-agent-gmqp7 1/1 Running 1 (24h ago) 24h eks-pod-identity-agent-prnsh 1/1 Running 1 (24h ago) 24h ``` Dadurch wird ein neues DaemonSet im `kube-system` Namespace eingerichtet. Der Amazon EKS Pod Identity Agent, der auf jedem EKS-Knoten ausgeführt wird, verwendet die [AssumeRoleForPodIdentity](https://docs.aws.amazon.com/eks/latest/APIReference/API_auth_AssumeRoleForPodIdentity.html)Aktion, um temporäre Anmeldeinformationen von der EKS Auth API abzurufen. Diese Anmeldeinformationen werden dann für die AWS SDKs , die Sie in Ihren Containern ausführen, zur Verfügung gestellt. Weitere Informationen finden Sie in den Voraussetzungen im öffentlichen Dokument: [Richten Sie den Amazon EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html) Agent ein. ## Eine Jobausführungsrolle erstellen ### Erstellen oder aktualisieren Sie die Jobausführungsrolle, die EKS Pod Identity ermöglicht Um Workloads mit Amazon EMR auf EKS auszuführen, müssen Sie eine IAM-Rolle erstellen. In dieser Dokumentation wird diese Rolle als Auftragsausführungsrolle bezeichnet. Weitere Informationen zum Erstellen der IAM-Rolle finden Sie unter [Erstellen von IAM-Rollen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html) im Benutzerhandbuch. Darüber hinaus müssen Sie eine IAM-Richtlinie erstellen, die die erforderlichen Berechtigungen für die Jobausführungsrolle festlegt, und diese Richtlinie dann an die Rolle anhängen, um EKS Pod Identity zu aktivieren. Sie haben beispielsweise die folgende Jobausführungsrolle. Weitere Informationen finden Sie unter [Erstellen einer Jobausführungsrolle](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/creating-job-execution-role.html). ``` arn:aws:iam::111122223333:role/PodIdentityJobExecutionRole ``` **Wichtig** Amazon EMR on EKS erstellt automatisch Kubernetes-Servicekonten auf der Grundlage Ihres Rollennamens für die Auftragsausführung. Stellen Sie sicher, dass der Rollenname nicht zu lang ist, da Ihr Job möglicherweise fehlschlägt, wenn die Kombination aus `cluster_name``pod_name`, und die `service_account_name` Längenbeschränkung überschreitet. **Konfiguration der Jobausführungsrolle** — Stellen Sie sicher, dass die Jobausführungsrolle mit der unten angegebenen Vertrauensberechtigung für EKS Pod Identity erstellt wurde. Um eine bestehende Jobausführungsrolle zu aktualisieren, konfigurieren Sie sie so, dass sie dem folgenden EKS-Dienstprinzipal als zusätzliche Berechtigung in der Vertrauensrichtlinie vertraut. Diese Vertrauensberechtigung kann zusammen mit bestehenden IRSA-Vertrauensrichtlinien verwendet werden. ``` cat >trust-relationship.json < ### Voraussetzung Stellen Sie sicher, dass die IAM-Identität, die die Pod-Identitätszuordnung erstellt, z. B. ein EKS-Administratorbenutzer, über die Berechtigung `eks:CreatePodIdentityAssociation` und `iam:PassRole` verfügt. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "eks:CreatePodIdentityAssociation" ], "Resource": [ "arn:aws:eks:*:*:cluster/*" ], "Sid": "AllowEKSCreatepodidentityassociation" }, { "Effect": "Allow", "Action": [ "iam:PassRole" ], "Resource": [ "arn:aws:iam::*:role/*" ], "Condition": { "StringEquals": { "iam:PassedToService": "pods.eks.amazonaws.com" } }, "Sid": "AllowIAMPassrole" } ] } ``` ------ ### Zuordnungen für die Rolle und das EMR-Dienstkonto erstellen ------ #### [ Create EMR role associations through the AWS CLI ] Wenn Sie einen Job an einen Kubernetes-Namespace senden, muss ein Administrator Verknüpfungen zwischen der Jobausführungsrolle und der Identität des EMR-verwalteten Dienstkontos erstellen. Beachten Sie, dass das EMR-verwaltete Servicekonto bei der Aufgabenübermittlung automatisch erstellt wird und auf den Namespace beschränkt ist, in dem die Aufgabe eingereicht wird. Führen Sie mit der AWS CLI (älteren Version 2.24.0) den folgenden Befehl aus, um Rollenzuordnungen mit der Pod-Identität zu erstellen. Führen Sie den folgenden Befehl aus, um Rollenzuordnungen mit der Pod-Identität zu erstellen: ``` aws emr-containers create-role-associations \ --cluster-name mycluster \ --namespace mynamespace \ --role-name JobExecutionRoleIRSAv2 ``` Hinweis: + Jeder Cluster kann ein Limit von 1.000 Verknüpfungen haben. Für jede Rolle zur Auftragsausführung — die Namespace-Zuordnung — sind drei Zuordnungen für die Pods für den Job-Absender, den Treiber und den Executor erforderlich. + Sie können nur Rollen zuordnen, die sich in demselben Konto wie AWS der Cluster befinden. Sie können den Zugriff von einem anderen Konto auf die Rolle in diesem Konto delegieren, die Sie für die Verwendung durch EKS-Pod-Identitäten konfigurieren. Ein Tutorial zum Delegieren von Zugriff und `AssumeRole` finden Sie unter [IAM-Tutorial: AWS Kontoübergreifendes Delegieren des Zugriffs mithilfe von](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html) IAM-Rollen. ------ #### [ Create EMR role associations through Amazon EKS ] EMR erstellt ein Dienstkonto mit einem bestimmten Benennungsmuster, wenn ein Job eingereicht wird. Gehen Sie folgendermaßen vor, um manuelle Verknüpfungen vorzunehmen oder diesen Workflow in das AWS SDK zu integrieren: Dienstkontonamen erstellen: ``` emr-containers-sa-spark-%(SPARK_ROLE)s-%(AWS_ACCOUNT_ID)s-%(BASE36_ENCODED_ROLE_NAME)s ``` In den folgenden Beispielen werden Rollenzuordnungen für eine Beispielrolle zur Jobausführung erstellt JobExecutionRoleIRSAv2. **Beispiele für Rollenzuordnungen:** ``` RoleName: JobExecutionRoleIRSAv2 Base36EncodingOfRoleName: 2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe ``` **Beispiel für einen CLI-Befehl:** ``` # setup for the client service account (used by job runner pod) # emr-containers-sa-spark-client-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe aws eks create-pod-identity-association --cluster-name mycluster --role-arn arn:aws:iam::111122223333:role/JobExecutionRoleIRSAv2 --namespace mynamespace --service-account emr-containers-sa-spark-client-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe # driver service account # emr-containers-sa-spark-driver-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe aws eks create-pod-identity-association --cluster-name mycluster --role-arn arn:aws:iam::111122223333:role/JobExecutionRoleIRSAv2 --namespace mynamespace --service-account emr-containers-sa-spark-driver-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe # executor service account # emr-containers-sa-spark-executor-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe aws eks create-pod-identity-association --cluster-name mycluster --role-arn arn:aws:iam::111122223333:role/JobExecutionRoleIRSAv2 --namespace mynamespace --service-account emr-containers-sa-spark-executor-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe ``` ------ Nachdem Sie alle für die EKS-Pod-Identität erforderlichen Schritte abgeschlossen haben, können Sie die folgenden Schritte für die IRSA-Einrichtung überspringen: + [Aktivieren Sie IAM-Rollen für Dienstkonten (IRSA) auf dem EKS-Cluster](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-enable-IAM.html) + [Erstellen Sie eine Rolle für die Auftragsausführung](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/creating-job-execution-role.html) + [Aktualisieren Sie die Vertrauensrichtlinie der Jobausführungsrolle](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-trust-policy.html) Sie können direkt mit dem folgenden Schritt fortfahren: [Benutzern Zugriff auf Amazon EMR auf EKS gewähren](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-iam.html) ## Rollenzuordnungen löschen Immer wenn Sie einen virtuellen Cluster oder eine Jobausführungsrolle löschen und den zugehörigen Dienstkonten keinen Zugriff mehr auf EMR gewähren möchten, sollten Sie die Zuordnungen für die Rolle löschen. Das liegt daran, dass EKS Verknüpfungen mit nicht vorhandenen Ressourcen (Namespace und Dienstkonto) zulässt. Amazon EMR on EKS empfiehlt, die Verknüpfungen zu löschen, wenn der Namespace gelöscht wird oder die Rolle nicht mehr verwendet wird, um Speicherplatz für andere Zuordnungen freizugeben. **Anmerkung** Die verbleibenden Verknüpfungen könnten sich möglicherweise auf Ihre Skalierbarkeit auswirken, wenn Sie sie nicht löschen, da bei EKS die Anzahl der Verknüpfungen, die Sie erstellen können, begrenzt ist (Soft-Limit: 1000 Verknüpfungen pro Cluster). Sie können Pod-Identitätszuordnungen in einem bestimmten Namespace auflisten, um zu überprüfen, ob Sie noch bestehende Assoziationen haben, die bereinigt werden müssen: ``` aws eks list-pod-identity-associations --cluster-name mycluster --namespace mynamespace ``` Führen Sie mit AWS CLI (Version 2.24.0 oder höher) den folgenden Befehl emr-containers aus, um die Rollenzuordnungen von EMR zu löschen: ``` aws emr-containers delete-role-associations \ --cluster-name mycluster \ --namespace mynamespace \ --role-name JobExecutionRoleIRSAv2 ``` ## Automatisches Migrieren vorhandener IRSA zu Pod Identity Sie können das Tool eksctl verwenden, um bestehende IAM-Rollen für Dienstkonten (IRSA) zu Pod-Identitätszuordnungen zu migrieren: ``` eksctl utils migrate-to-pod-identity \ --cluster mycluster \ --remove-oidc-provider-trust-relationship \ --approve ``` Wenn Sie den Befehl ohne das `--approve` Kennzeichen ausführen, wird nur ein Plan ausgegeben, der die Migrationsschritte widerspiegelt, und es findet keine tatsächliche Migration statt. ## Fehlerbehebung ### Mein Job ist mit NoClassDefinitionFound oder ClassNotFound Exception for Credentials Provider fehlgeschlagen, oder der Credentials Provider konnte nicht abgerufen werden. EKS Pod Identity verwendet den Container Credentials Provider, um die erforderlichen Anmeldeinformationen abzurufen. Wenn Sie einen Anbieter für benutzerdefinierte Anmeldeinformationen angegeben haben, stellen Sie sicher, dass dieser ordnungsgemäß funktioniert. Stellen Sie alternativ sicher, dass Sie eine korrekte AWS SDK-Version verwenden, die die EKS Pod Identity unterstützt. Weitere Informationen finden Sie unter [Erste Schritte mit Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html). ### Der Job schlug fehl und im eks-pod-identity-agent Protokoll wurde der Fehler „Anmeldeinformationen konnten aufgrund von [x] Größenbeschränkung nicht abgerufen werden“ angezeigt. EMR on EKS erstellt Kubernetes-Dienstkonten auf der Grundlage des Namens der Jobausführungsrolle. Wenn der Rollenname zu lang ist, kann EKS Auth die Anmeldeinformationen nicht abrufen, da die Kombination aus `cluster_name``pod_name`, und die Längenbeschränkung `service_account_name` überschreitet. Identifizieren Sie, welche Komponente den meisten Platz beansprucht, und passen Sie die Größe entsprechend an. ### Der Job schlug fehl, und im eks-pod-identity Protokoll wurde der Fehler „Anmeldeinformationen nicht abgerufen xxx“ angezeigt. Eine mögliche Ursache für dieses Problem könnte sein, dass der EKS-Cluster in privaten Subnetzen konfiguriert ist, ohne dass er PrivateLink für den Cluster korrekt konfiguriert wurde. Überprüfen Sie, ob sich Ihr Cluster in einem privaten Netzwerk befindet, und konfigurieren Sie ihn AWS PrivateLink , um das Problem zu beheben. Eine ausführliche Anleitung finden Sie unter [Erste Schritte mit Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html). # Option 2: Aktivieren Sie IAM-Rollen für Service Accounts (IRSA) auf dem EKS-Cluster Das Feature IAM-Rollen für Servicekonten ist auf der neuen Amazon-EKS-Version 1.14 und höher und auf EKS Clustern verfügbar, die am oder nach dem 3. September 2019 auf die Version 1.13 oder höher aktualisiert wurden. Um dieses Feature zu nutzen, können Sie vorhandene EKS-Cluster auf Version 1.14 oder höher aktualisieren. Weitere Informationen finden Sie unter [Aktualisieren einer Amazon-EKS-Cluster-Kubernetes-Version](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html). Wenn Ihr Cluster IAM-Rollen für Servicekonten unterstützt, ist ihm eine [OpenID-Connect](https://openid.net/connect/)-Aussteller-URL zugeordnet. Sie können diese URL in der Amazon EKS-Konsole anzeigen oder den folgenden AWS CLI Befehl verwenden, um sie abzurufen. **Wichtig** Sie müssen die neueste Version von verwenden AWS CLI , um die korrekte Ausgabe dieses Befehls zu erhalten. ``` aws eks describe-cluster --name cluster_name --query "cluster.identity.oidc.issuer" --output text ``` Die erwartete Ausgabe sieht wie folgt aus. ``` https://oidc.eks..amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E ``` Um IAM-Rollen für Servicekonten in Ihrem Cluster zu verwenden, müssen Sie einen OIDC-Identitätsanbieter entweder mit [eksctl](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html#create-oidc-eksctl) oder [AWS-Managementkonsole](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html#create-oidc-console) erstellen. ## So erstellen Sie einen IAM-OIDC-Identitätsanbieter für Ihren Cluster mit `eksctl` Sie können Ihre `eksctl`-Version mit dem folgenden Befehl überprüfen. Bei diesem Verfahren wird davon ausgegangen, dass Sie `eksctl` installiert haben und dass Ihre `eksctl`-Version mindestens 0.32.0 oder höher ist. ``` eksctl version ``` Weitere Informationen über die Installation oder Aktualisierung von eksctl finden Sie unter [Installieren oder Aktualisieren von eksctl](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html#installing-eksctl). Erstellen Sie Ihren OIDC-Identitätsanbieter für Ihren Cluster mit dem folgenden Befehl. Ersetzen Sie *cluster\$1name* durch Ihren eigenen Wert. ``` eksctl utils associate-iam-oidc-provider --cluster cluster_name --approve ``` ## Um einen IAM-OIDC-Identitätsanbieter für Ihren Cluster mit dem zu erstellen AWS-Managementkonsole Rufen Sie die OIDC-Aussteller-URL aus der Amazon EKS-Konsolenbeschreibung Ihres Clusters ab, oder verwenden Sie den folgenden Befehl. AWS CLI Verwenden Sie den folgenden Befehl, um die OIDC-Aussteller-URL aus der AWS CLI abzurufen. ``` aws eks describe-cluster --name --query "cluster.identity.oidc.issuer" --output text ``` Führen Sie die folgenden Schritte aus, um die OIDC-Aussteller-URL von der Amazon-EKS-Konsole abzurufen. 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 **Identitätsanbieter** und dann **Anbieter erstellen** aus. 1. Wählen Sie für **Provider Type (Anbietertyp)** die Option **Choose a provider type (Anbietertyp auswählen)** und dann **OpenID Connect** aus. 1. Fügen Sie unter **Provider URL (Anbieter-URL)** die OIDC-Aussteller-URL für Ihren Cluster ein. 1. Geben Sie für Zielgruppe sts.amazonaws.com ein und wählen Sie **Nächster Schritt** aus. 1. Überprüfen Sie, ob die Anbieterinformationen korrekt sind, und wählen Sie dann **Create (Erstellen)** aus, um Ihren Identitätsanbieter zu erstellen. # Erstellen einer Aufgabenausführungsrolle Um Workloads auf Amazon EMR in EKS auszuführen, müssen Sie eine IAM-Rolle erstellen. In dieser Dokumentation wird diese Rolle als *Auftragsausführungsrolle* bezeichnet. Weitere Informationen zum Erstellen von IAM-Rollen finden Sie unter [Erstellen von IAM-Rollen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html) im IAM-Benutzerhandbuch. Sie müssen außerdem eine IAM-Richtlinie erstellen, die die Berechtigungen für die Auftragsausführungsrolle festlegt, und dann die IAM-Richtlinie an die Auftragsausführungsrolle anhängen. Die folgende Richtlinie für die Jobausführungsrolle ermöglicht den Zugriff auf Ressourcenziele, Amazon S3 und CloudWatch. Diese Berechtigungen sind erforderlich, um Aufträge und Zugriffsprotokolle zu überwachen. Um dem gleichen Prozess zu folgen, verwenden Sie AWS CLI: IAM-Rolle für die Jobausführung erstellen: Lassen Sie uns die Rolle erstellen, die EMR für die Jobausführung verwenden wird. Dies ist die Rolle, die EMR-Jobs übernehmen, wenn sie auf EKS ausgeführt werden. ``` cat < ~/environment/emr-trust-policy.json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "elasticmapreduce.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } EoF aws iam create-role --role-name EMRContainers-JobExecutionRole --assume-role-policy-document file://~/environment/emr-trust-policy.json ``` Als Nächstes müssen wir der Rolle die erforderlichen IAM-Richtlinien hinzufügen, damit sie Protokolle in S3 und Cloudwatch schreiben kann. ``` cat < ~/environment/EMRContainers-JobExecutionRole.json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:ListBucket" ], "Resource": "arn:aws:s3:::amzn-s3-demo-bucket" }, { "Effect": "Allow", "Action": [ "logs:PutLogEvents", "logs:CreateLogStream", "logs:DescribeLogGroups", "logs:DescribeLogStreams" ], "Resource": [ "arn:aws:logs:*:*:*" ] } ] } EoF aws iam put-role-policy --role-name EMRContainers-JobExecutionRole --policy-name EMR-Containers-Job-Execution --policy-document file://~/environment/EMRContainers-JobExecutionRole.json ``` **Anmerkung** Der Zugriff sollte angemessen begrenzt sein und nicht allen S3-Objekten in der Rolle Aufgabenausführung gewährt werden. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket" ], "Sid": "AllowS3Putobject" }, { "Effect": "Allow", "Action": [ "logs:PutLogEvents", "logs:CreateLogStream", "logs:DescribeLogGroups", "logs:DescribeLogStreams" ], "Resource": [ "arn:aws:logs:*:*:*" ], "Sid": "AllowLOGSPutlogevents" } ] } ``` ------ Weitere Informationen finden Sie unter [Verwenden von Rollen zur Jobausführung](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/iam-execution-role.html), [Konfigurieren eines Joblaufs für die Verwendung von S3-Protokollen](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-s3) und [Konfigurieren eines Joblaufs für die Verwendung CloudWatch ](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-cloudwatch) von Logs. # Die Vertrauensrichtlinie der Auftragsausführungsrolle aktualisieren Wenn Sie IAM-Rollen für Servicekonten (IRSA) verwenden, um Aufträge in einem Kubernetes-Namespace auszuführen, muss ein Administrator eine Vertrauensbeziehung zwischen der Auftragsausführungsrolle und der Identität des EMR-verwalteten Servicekontos einrichten. Die Vertrauensbeziehung kann hergestellt werden, indem die Vertrauensrichtlinie der Auftragsausführungsrolle aktualisiert wird. Beachten Sie, dass das EMR-verwaltete Servicekonto bei der Aufgabenübermittlung automatisch erstellt wird und auf den Namespace beschränkt ist, in dem die Aufgabe eingereicht wird. Um die Vertrauensrichtlinie zu aktualisieren, führen Sie den folgenden Befehl aus. ``` aws emr-containers update-role-trust-policy \ --cluster-name cluster \ --namespace namespace \ --role-name iam_role_name_for_job_execution ``` Weitere Informationen finden Sie unter [Auftragausführungsrollen mit Amazon EMR in EKS verwenden](iam-execution-role.md). **Wichtig** Der Operator, der den obigen Befehl ausführt, muss über die folgenden Berechtigungen verfügen: `eks:DescribeCluster` `iam:GetRole` `iam:UpdateAssumeRolePolicy`.