**Unterstützung für die Verbesserung dieser Seite beitragen** 

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.

Um zu diesem Benutzerhandbuch beizutragen, wählen Sie den GitHub Link **Diese Seite bearbeiten auf**, der sich im rechten Bereich jeder Seite befindet.

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.

# Erfahren Sie, wie EKS Pod Identity Pods Zugriff auf AWS-Services gewährt
<a name="pod-identities"></a>

Die Anwendungen in den Containern eines Pods können ein AWS-SDK oder die AWS-CLI verwenden, um API-Anforderungen an AWS-Services mithilfe von AWS Identity and Access Management (IAM)-Berechtigungen zu senden. Die Anwendungen müssen ihre AWS-API-Anforderungen mit AWS-Anmeldeinformationen signieren.

 *EKS-Pod-Identitäten* bieten die Möglichkeit, Anmeldeinformationen für Ihre Anwendungen zu verwalten, ähnlich wie Amazon-EC2-Instance-Profile Anmeldeinformationen für Amazon-EC2-Instances bereitstellen. Anstatt Ihre AWS-Anmeldeinformationen zu erstellen und an die Container zu verteilen oder die Rolle der Amazon-EC2-Instance zu verwenden, verknüpfen Sie eine IAM-Rolle mit einem Kubernetes-Servicekonto und konfigurieren Ihre Pods so, dass sie das Servicekonto verwenden.

[![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/aUjJSorBE70?rel=0/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/aUjJSorBE70?rel=0)


Jede EKS-Pod-Identity-Zuordnung ordnet einem Servicekonto in einem Namespace im angegebenen Cluster eine Rolle zu. Wenn Sie dieselbe Anwendung in mehreren Clustern haben, können Sie in jedem Cluster identische Zuordnungen vornehmen, ohne die Vertrauensrichtlinie der Rolle zu ändern.

Wenn ein Pod ein Servicekonto mit einer Zuordnung verwendet, legt Amazon EKS Umgebungsvariablen in den Containern des Pods fest. Die Umgebungsvariablen konfigurieren die AWS-SDKs, einschließlich der AWS-CLI, für die Verwendung der Anmeldeinformationen für EKS Pod Identity.

## Vorteile von EKS-Pod-Identitäten
<a name="pod-id-benefits"></a>

EKS-Pod-Identitäten bieten die folgenden Vorteile:
+  **Geringste Berechtigung** – Sie können IAM-Berechtigungen auf ein Servicekonto beschränken, und nur Pods, die dieses Servicekonto verwenden, haben Zugriff auf diese Berechtigungen. Mit diesem Feature entfällt auch die Notwendigkeit von Drittanbieterlösungen wie `kiam` oder `kube2iam`.
+  **Isolierung von Anmeldeinformationen** – Wenn der Zugriff auf den [Amazon EC2 Instance Metadata Service (IMDS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html) eingeschränkt ist, können die Container eines Pods nur Anmeldeinformationen für die IAM-Rolle abrufen, die dem vom Container verwendeten Servicekonto zugeordnet ist. Ein Container hat nie Zugriff auf Anmeldeinformationen, die von anderen Containern in anderen Pods verwendet werden. Wenn IMDS nicht eingeschränkt ist, haben die Container des Pods auch Zugriff auf die [IAM-Rolle des Amazon-EKS-Knotens](create-node-role.md) und die Container können möglicherweise auf Anmeldeinformationen von IAM-Rollen anderer Pods auf demselben Knoten zugreifen. Weitere Informationen finden Sie unter [Beschränken Sie den Zugriff auf das Instance-Profil, das dem Worker-Knoten zugewiesen ist](https://docs.aws.amazon.com/eks/latest/best-practices/identity-and-access-management.html#_identities_and_credentials_for_eks_pods_recommendations).

**Anmerkung**  
Mit `hostNetwork: true` konfigurierte Pods haben immer IMDS-Zugriff, aber die AWS-SDKs und die CLI verwenden bei Aktivierung die Pod-Identity-Anmeldeinformationen.
+  **Überprüfbarkeit** – Die Zugriffs- und Ereignisprotokollierung ist über AWS CloudTrail verfügbar, um eine nachträgliche Überprüfung zu vereinfachen.

**Wichtig**  
Container stellen keine Sicherheitsgrenze dar und die Verwendung von Pod Identity ändert daran nichts. Pods, die demselben Knoten zugewiesen sind, teilen sich einen Kernel und möglicherweise andere Ressourcen, abhängig von Ihrer Pod-Konfiguration. Während Pods, die auf separaten Knoten ausgeführt werden, auf der Rechenebene isoliert sind, gibt es Knotenanwendungen, die über zusätzliche Berechtigungen in der Kubernetes-API verfügen, die über den Umfang einer einzelnen Instance hinausgehen. Einige Beispiele sind `kubelet`, `kube-proxy`, CSI-Speichertreiber oder Ihre eigenen Kubernetes-Anwendungen.

EKS Pod Identity ist eine einfachere Methode als [IAM-Rollen für Servicekonten](iam-roles-for-service-accounts.md), da diese keine OIDC-Identitätsanbieter nutzt. EKS Pod Identity bietet die folgenden Verbesserungen:
+  **Unabhängiger Betrieb** – In vielen Organisationen liegt die Verantwortung für die Erstellung von OIDC-Identitätsanbietern bei anderen Teams als für die Verwaltung der Kubernetes-Cluster. EKS Pod Identity hat eine klare Aufgabentrennung: Die gesamte Konfiguration der EKS-Pod-Identity-Zuordnungen erfolgt in Amazon EKS und die gesamte Konfiguration der IAM-Berechtigungen erfolgt in IAM.
+  **Wiederverwendbarkeit** – EKS Pod Identity verwendet einen einzigen IAM-Prinzipal anstelle der separaten Prinzipale für jeden Cluster, den IAM-Rollen für Servicekonten verwenden. Ihr IAM-Administrator fügt der Vertrauensrichtlinie jeder Rolle den folgenden Prinzipal hinzu, damit sie von EKS-Pod-Identitäten verwendet werden kann.

  ```
              "Principal": {
                  "Service": "pods.eks.amazonaws.com"
              }
  ```
+  **Skalierbarkeit** – Jeder Satz temporärer Anmeldeinformationen wird vom EKS-Service in EKS Pod Identity angenommen statt von jedem AWS-SDK, das Sie in jedem Pod ausführen. Anschließend stellt der Amazon EKS Pod Identity Agent, der auf jedem Knoten ausgeführt wird, die Anmeldeinformationen an die SDKs aus. Dadurch wird die Last für jeden Knoten reduziert und nicht in jedem Pod dupliziert. Weitere Details zu diesem Prozess finden Sie unter [Funktionsweise von EKS Pod Identity verstehen](pod-id-how-it-works.md).

Weitere Informationen zum Vergleich der beiden Alternativen finden Sie unter [Kubernetes-Workloads Zugriff auf AWS mithilfe von Kubernetes-Servicekonten gewähren](service-accounts.md).

## Übersicht über die Einrichtung von EKS-Pod-Identitäten
<a name="pod-id-setup-overview"></a>

Aktivieren Sie EKS-Pod-Identitäten, indem Sie die folgenden Verfahren ausführen:

1.  [Einrichtung des Amazon-EKS-Pod-Identity-Agenten](pod-id-agent-setup.md) – Sie führen diesen Vorgang für jeden Cluster nur einmal durch. Sie müssen diesen Schritt nicht ausführen, wenn EKS Auto Mode in Ihrem Cluster aktiviert ist.

1.  [Zuordnung einer IAM-Rolle einem Kubernetes-Servicekonto](pod-id-association.md) – Führen Sie dieses Verfahren für jeden einzelnen Berechtigungssatz durch, den eine Anwendung haben soll.

1.  [Pods für den Zugriff auf AWS Dienste mit Dienstkonten konfigurieren](pod-id-configure-pods.md) – Führen Sie dieses Verfahren für jeden Pod durch, der Zugriff auf AWS-Services benötigt.

1.  [Verwendung der Pod Identity mit dem AWS-SDK](pod-id-minimum-sdk.md) – Stellen Sie sicher, dass der Workload ein AWS-SDK einer unterstützten Version verwendet und dass der Workload die Kette standardmäßiger Anmeldeinformationen verwendet.

## Grenzwerte
<a name="pod-id-limits"></a>
+ Pro Cluster werden bis zu 5 000 EKS-Pod-Identity-Zuordnungen unterstützt, um IAM-Rollen Kubernetes-Servicekonten zuzuordnen.

## Überlegungen
<a name="pod-id-considerations"></a>
+  **IAM-Rollenzuordnung**: Jedes Kubernetes-Servicekonto in einem Cluster kann einer IAM-Rolle aus demselben AWS-Konto wie das Cluster zugeordnet werden. Sie ändern die Rolle, indem Sie die EKS-Pod-Identity-Zuordnung bearbeiten. Für den kontenübergreifenden Zugriff delegieren Sie den Zugriff auf die Rolle mithilfe von IAM-Rollen. Weitere Informationen finden Sie unter [Delegieren des Zugriffs über alle AWS-Konten hinweg mithilfe von IAM-Rollen](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html) im *IAM-Benutzerhandbuch*.
+  **EKS-Pod-Identity-Agent**: Der Pod-Identity-Agent ist zur Verwendung von EKS Pod Identity erforderlich. Der Agent wird als Kubernetes `DaemonSet` in Cluster-Knoten ausgeführt und stellt Anmeldeinformationen nur für Pods auf demselben Knoten bereit. Er verwendet das `hostNetwork` des Knotens und belegt die Ports `80` und `2703` auf der link-lokalen Adresse (`169.254.170.23` für IPv4, `[fd00:ec2::23]` für IPv6). Wenn IPv6 in Ihrem Cluster deaktiviert ist, deaktivieren Sie IPv6 für den Pod-Identity-Agent. Weitere Informationen finden Sie unter [IPv6 im EKS-Pod-Identity-Agent deaktivieren](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-config-ipv6.html).
+  **Eventuelle Konsistenz**: EKS-Pod-Identity-Zuordnungen sind letztendlich konsistent, mit möglichen Verzögerungen von mehreren Sekunden nach API-Aufrufen. Vermeiden Sie die Erstellung oder Aktualisierung von Verknüpfungen in kritischen Code-Pfaden mit hoher Verfügbarkeit. Führen Sie diese Aktionen stattdessen in separaten, weniger häufigen Initialisierungs- oder Einrichtungsroutinen durch. Weitere Informationen finden Sie unter [Sicherheitsgruppen pro Pod](https://docs.aws.amazon.com/eks/latest/best-practices/sgpp.html) im *EKS-Leitfaden für bewährte Methoden*.
+  **Überlegungen zu Proxy und Sicherheitsgruppe**: Bei Pods, die einen Proxy verwenden, fügen Sie `169.254.170.23` (IPv4) und `[fd00:ec2::23]` (IPv6) zu den `no_proxy/NO_PROXY`-Umgebungsvariablen hinzu, um fehlgeschlagene Anfragen an den EKS-Pod-Identity-Agent zu vermeiden. Wenn Sie Sicherheitsgruppen für Pods mit AWS VPC CNI verwenden, setzen Sie das `ENABLE_POD_ENI`-Flag auf „true“ und das `POD_SECURITY_GROUP_ENFORCING_MODE`-Flag auf „standard“. Weitere Informationen finden Sie unter [Zuweisen von Sicherheitsgruppen zu einzelnen Pods](https://docs.aws.amazon.com/eks/latest/userguide/security-groups-for-pods.html).

### Cluster-Versionen von EKS Pod Identity
<a name="pod-id-cluster-versions"></a>

Um EKS Pod Identity nutzen zu können, muss der Cluster über eine Plattformversion verfügen, die mindestens der in der folgenden Tabelle aufgeführten Version entspricht, oder über eine Kubernetes-Version, die neuer ist als die in der Tabelle aufgeführten Versionen. Die empfohlene Version des Amazon-EKS-Pod-Identity-Agent für eine Kubernetes-Version finden Sie unter [Kompatibilität der Add-On-Version von Amazon EKS mit einem Cluster überprüfen](addon-compat.md).


| Kubernetes-Version | Plattformversion | 
| --- | --- | 
|  Nicht aufgeführte Kubernetes-Versionen  |  Alle Plattformversionen werden unterstützt  | 
|   `1.28`   |   `eks.4`   | 

### Einschränkungen von EKS Pod Identity
<a name="pod-id-restrictions"></a>

EKS-Pod-Identitäten sind auf folgenden Plattformen verfügbar:
+ Amazon-EKS-Cluster-Versionen, die im vorherigen Thema ([Cluster-Versionen von EKS Pod Identity](#pod-id-cluster-versions)) aufgeführt wurden.
+ Worker-Knoten im Cluster, die Linux-Amazon-EC2-Instances sind.

EKS Pod Identities sind auf folgenden Plattformen nicht verfügbar:
+  AWS Outposts
+ Amazon EKS Anywhere.
+ Kubernetes-Cluster, die Sie in Amazon EC2 erstellen und ausführen. Die EKS-Pod-Identity-Komponenten sind nur in Amazon EKS verfügbar.

Sie können EKS Pod Identities nicht verwenden mit:
+ Pods, die nicht auf Linux-Amazon-EC2-Instances ausgeführt werden. Linux- und Windows-Pods, die in AWS Fargate (Fargate) ausgeführt werden, werden nicht unterstützt. In Windows-Amazon-EC2-Instances ausgeführte Pods werden nicht unterstützt.

# Funktionsweise von EKS Pod Identity verstehen
<a name="pod-id-how-it-works"></a>

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.

In Ihren Add-ons, z. B. *Amazon-EKS-Add-ons* und Add-ons für selbstverwaltete Controller und Operatoren, muss der Autor seine Software aktualisieren, um die neuesten AWS-SDKs verwenden zu können. Die Liste der Kompatibilität zwischen EKS Pod Identity und den von Amazon EKS produzierten Add-ons finden Sie im vorherigen Abschnitt ([Einschränkungen von EKS Pod Identity](pod-identities.md#pod-id-restrictions)).

## Verwenden von EKS-Pod-Identitäten in Ihrem Code
<a name="pod-id-credentials"></a>

In Ihrem Code können Sie die AWS-SDKs verwenden, um auf AWS-Services zuzugreifen. Sie schreiben Code, um einen Client für einen AWS-Service mit einem SDK zu erstellen. Standardmäßig sucht das SDK in einer Kette von Speicherorten nach zu verwendenden Anmeldeinformationen für AWS-Identitäts- und Zugriffsverwaltung. Nachdem gültige Anmeldeinformationen gefunden wurden, wird die Suche beendet. Weitere Informationen zu den verwendeten Standardspeicherorten finden Sie unter [Anbieterkette von Anmeldeinformationen](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html#credentialProviderChain) im Referenzhandbuch für AWS-SDKs und -Tools.

EKS-Pod-Identitäten wurden dem *Anbieter für Container-Anmeldeinformationen* hinzugefügt, der in einem Schritt in der standardmäßigen Anmeldeinformationskette durchsucht wird. Wenn Ihre Workloads derzeit Anmeldeinformationen verwenden, die in der Kette der Anmeldeinformationen weiter vorn stehen, werden diese Anmeldeinformationen auch dann weiter verwendet, wenn Sie eine EKS-Pod-Identity-Zuordnung für dieselbe Workload konfigurieren. Auf diese Weise können Sie sicher von anderen Anmeldeinformationstypen migrieren, indem Sie die Zuordnung erstellen, bevor Sie die alten Anmeldeinformationen entfernen.

Der Anbieter für Container-Anmeldeinformationen stellt temporäre Anmeldeinformationen über einen Agent bereit, der auf jedem Knoten ausgeführt wird. In Amazon EKS ist dies der Amazon EKS Pod Identity Agent und bei Amazon Elastic Container Service ist es der `amazon-ecs-agent`. Die SDKs verwenden Umgebungsvariablen, um den Agent zu finden, zu dem eine Verbindung hergestellt werden soll.

Im Gegensatz dazu stellen *IAM-Rollen für Servicekonten* ein Token für *Web-Identität* bereit, welches das AWS-SDK mithilfe von `AssumeRoleWithWebIdentity` mit dem AWS-Sicherheitstoken-Service austauschen muss.

## Funktionsweise von EKS-Pod-Identity-Agent mit einem Pod
<a name="pod-id-agent-pod"></a>

1. Wenn Amazon EKS einen neuen Pod startet, der ein Servicekonto mit einer EKS-Pod-Identity-Zuordnung verwendet, fügt der Cluster dem Pod-Manifest den folgenden Inhalt hinzu:

   ```
       env:
       - name: AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE
         value: "/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token"
       - name: AWS_CONTAINER_CREDENTIALS_FULL_URI
         value: "http://169.254.170.23/v1/credentials"
       volumeMounts:
       - mountPath: "/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/"
         name: eks-pod-identity-token
     volumes:
     - name: eks-pod-identity-token
       projected:
         defaultMode: 420
         sources:
         - serviceAccountToken:
             audience: pods.eks.amazonaws.com
             expirationSeconds: 86400 # 24 hours
             path: eks-pod-identity-token
   ```

1. Kubernetes wählt aus, auf welchem ​​Knoten der Pod ausgeführt werden soll. Anschließend verwendet der Amazon EKS Pod Identity Agent im Knoten die Aktion [AssumeRoleForPodIdentity](https://docs.aws.amazon.com/eks/latest/APIReference/API_auth_AssumeRoleForPodIdentity.html), um von der EKS-Auth-API temporäre Anmeldeinformationen abzurufen.

1. Der EKS Pod Identity Agent stellt diese Anmeldeinformationen für die AWS-SDKs zur Verfügung, die Sie in Ihren Containern ausführen.

1. Sie nutzen das SDK in Ihrer Anwendung, ohne einen Anmeldeinformationsanbieter für die Verwendung der standardmäßigen Anmeldeinformationskette anzugeben. Oder Sie geben den Anbieter für Container-Anmeldeinformationen an. Weitere Informationen zu den verwendeten Standardspeicherorten finden Sie unter [Anbieterkette von Anmeldeinformationen](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html#credentialProviderChain) im Referenzhandbuch für AWS-SDKs und -Tools.

1. Das SDK verwendet die Umgebungsvariablen, um eine Verbindung zum EKS Pod Identity Agent herzustellen und die Anmeldeinformationen abzurufen.
**Anmerkung**  
Wenn Ihre Workloads derzeit Anmeldeinformationen verwenden, die in der Kette der Anmeldeinformationen weiter vorn stehen, werden diese Anmeldeinformationen auch dann weiter verwendet, wenn Sie eine EKS-Pod-Identity-Zuordnung für dieselbe Workload konfigurieren.

# Einrichtung des Amazon-EKS-Pod-Identity-Agenten
<a name="pod-id-agent-setup"></a>

Amazon EKS Pod Identity-Zuordnungen bieten die Möglichkeit, Anmeldeinformationen für Ihre Anwendungen zu verwalten, ähnlich wie EC2 Amazon-Instance-Profile Anmeldeinformationen für EC2 Amazon-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.

**Tipp**  
Es ist nicht erforderlich, den EKS-Pod-Identity-Agent auf EKS-Auto-Mode-Clustern zu installieren. Diese Funktion ist in EKS Auto Mode integriert.

## Überlegungen
<a name="pod-id-agent-considerations"></a>
+ Standardmäßig ist der EKS-Pod-Identity-Agent auf EKS-Auto-Mode-Clustern vorinstalliert. Weitere Informationen hierzu finden Sie unter [Automatisieren der Cluster-Infrastruktur mit dem EKS-Automatikmodus](automode.md).
+ Standardmäßig überwacht der EKS-Pod-Identity-Agent eine `IPv4`- und `IPv6`-Adresse auf Pods, die Anmeldeinformationen anfordern. Der Agent verwendet die Loopback-IP-Adresse (localhost) `169.254.170.23` für `IPv4` und die localhost-IP-Adresse `[fd00:ec2::23]` für `IPv6`.
+ Wenn Sie `IPv6`-Adressen deaktivieren oder localhost-IP-Adressen `IPv6` anderweitig verhindern, kann der Agent nicht gestartet werden. Um den Agenten auf Knoten zu starten, die `IPv6` nicht verwenden können, befolgen Sie die Schritte unter [Deaktivierung von `IPv6` im EKS-Pod-Identity-Agent](pod-id-agent-config-ipv6.md), um die `IPv6`-Konfiguration zu deaktivieren.

## Erstellen des Amazon EKS Pod Identity Agent
<a name="pod-id-agent-add-on-create"></a>

### Voraussetzungen für den Agent
<a name="pod-id-agent-prereqs"></a>
+ Ein vorhandener Amazon-EKS-Cluster. Informationen zum Bereitstellen finden Sie unter [Erste Schritte mit Amazon EKS](getting-started.md). Die Cluster-Version und die Plattformversion müssen mit den in den [EKS-Pod-Identity-Cluster-Versionen](pod-identities.md#pod-id-cluster-versions) aufgeführten Versionen übereinstimmen oder höher sein.
+ Die Knotenrolle verfügt über Berechtigungen für den Agent, um die `AssumeRoleForPodIdentity`-Aktion in der EKS-Auth-API auszuführen. Sie können die [AWS verwaltete Richtlinie verwenden: Amazon EKSWorker NodePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksworkernodepolicy) oder eine benutzerdefinierte Richtlinie hinzufügen, die der folgenden ähnelt:

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "eks-auth:AssumeRoleForPodIdentity"
              ],
              "Resource": "*"
          }
      ]
  }
  ```

  Diese Aktion kann durch Tags beschränkt werden, um einzuschränken, welche Rollen von Pods übernommen werden können, die den Agent verwenden.
+ Die Knoten können auf Amazon ECR zugreifen und Images von Amazon ECR herunterladen. Das Container-Image für das Add-On befindet sich in den Registies, die unter [Amazon-Container-Image-Registries für Amazon-EKS-Add-Ons anzeigen](add-ons-images.md) aufgeführt sind.

  Beachten Sie, dass Sie den Speicherort des Images ändern und EKS-Add-Ons in den **optionalen Konfigurationseinstellungen** in der AWS-Managementkonsole und `--configuration-values` in der AWS CLI bereitstellen `imagePullSecrets` können.
+ Die Knoten können die Amazon-EKS-Auth-API erreichen. Für private Cluster ist der `eks-auth` AWS PrivateLink Endpunkt-Eingang erforderlich.

### Agent mit AWS Konsole einrichten
<a name="setup_agent_with_shared_aws_console"></a>

1. Öffnen Sie die [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 **Konfigurieren ausgewählter Add-ons-Einstellungen** eine beliebige Version in der Dropdown-Liste **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, dass die EKS-Pod-Identity-Pods auf Ihrem Cluster ausgeführt werden.

   ```
   kubectl get pods -n kube-system | grep 'eks-pod-identity-agent'
   ```

   Eine Beispielausgabe sieht wie folgt aus.

   ```
   eks-pod-identity-agent-gmqp7                                          1/1     Running   1 (24h ago)   24h
   eks-pod-identity-agent-prnsh                                          1/1     Running   1 (24h ago)   24h
   ```

   Sie können jetzt EKS-Pod-Identity-Zuordnungen in Ihrem Cluster verwenden. Weitere Informationen finden Sie unter [Zuordnung einer IAM-Rolle einem Kubernetes-Servicekonto](pod-id-association.md).

### Agent mit AWS CLI einrichten
<a name="setup_agent_with_shared_aws_cli"></a>

1. Führen Sie den folgenden AWS CLI-Befehl aus. Ersetzen Sie `my-cluster` mit dem Namen Ihres Clusters.

   ```
   aws eks create-addon --cluster-name my-cluster --addon-name eks-pod-identity-agent --addon-version v1.0.0-eksbuild.1
   ```
**Anmerkung**  
Der EKS-Pod-Identity-Agent verwendet den `service-account-role-arn` nicht für *IAM-Rollen für Servicekonten*. Sie müssen dem EKS Pod Identity Agent Berechtigungen für die Knotenrolle gewähren.

1. Vergewissern Sie sich, dass die EKS-Pod-Identity-Pods auf Ihrem Cluster ausgeführt werden.

   ```
   kubectl get pods -n kube-system | grep 'eks-pod-identity-agent'
   ```

   Eine Beispielausgabe sieht wie folgt aus.

   ```
   eks-pod-identity-agent-gmqp7                                          1/1     Running   1 (24h ago)   24h
   eks-pod-identity-agent-prnsh                                          1/1     Running   1 (24h ago)   24h
   ```

   Sie können jetzt EKS-Pod-Identity-Zuordnungen in Ihrem Cluster verwenden. Weitere Informationen finden Sie unter [Zuordnung einer IAM-Rolle einem Kubernetes-Servicekonto](pod-id-association.md).

# Zuordnung einer IAM-Rolle einem Kubernetes-Servicekonto
<a name="pod-id-association"></a>

In diesem Thema wird beschrieben, wie Sie ein Kubernetes-Dienstkonto so konfigurieren, dass es eine AWS Identity and Access Management (IAM) -Rolle mit EKS Pod Identity annimmt. Alle Pods, die für die Verwendung des Dienstkontos konfiguriert sind, können dann auf jeden AWS Dienst zugreifen, für den die Rolle über Zugriffsberechtigungen verfügt.

Um eine EKS Pod Identity-Zuordnung zu erstellen, gibt es nur einen einzigen Schritt: Sie erstellen die Zuordnung in EKS über die AWS CLI AWS-Managementkonsole AWS SDKs, AWS CloudFormation und andere Tools. Es gibt keine Daten oder Metadaten zu den Zuordnungen innerhalb des Clusters in Kubernetes-Objekten, und Sie fügen den Servicekonten keine Annotationen hinzu

 **Voraussetzungen** 
+ Einen vorhandenen -Cluster. Falls Sie noch kein Service-Konto haben, können Sie eines erstellen, indem Sie einer der Anleitungen in [Erste Schritte mit Amazon EKS](getting-started.md) folgen.
+ Der IAM-Prinzipal, der die Zuordnung erstellt, muss `iam:PassRole` haben.
+ Die neueste Version der AWS CLI, die auf Ihrem Gerät installiert und konfiguriert ist, oder AWS CloudShell. Sie können Ihre aktuelle Version mit `aws --version | cut -d / -f2 | cut -d ' ' -f1` überprüfen. Paketmanager wie `yum``apt-get`, oder Homebrew für macOS liegen oft mehrere Versionen hinter der neuesten Version der AWS CLI. Informationen zur Installation der neuesten Version finden Sie unter [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) und [Schnellkonfiguration mit aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) im Benutzerhandbuch für die AWS Befehlszeilenschnittstelle. Die in der installierte AWS CLI-Version AWS CloudShell kann auch mehrere Versionen hinter der neuesten Version liegen. Informationen zur Aktualisierung finden Sie im AWS CloudShell Benutzerhandbuch unter [AWS CLI in Ihrem Home-Verzeichnis installieren](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software).
+ Das `kubectl`-Befehlszeilen-Tool ist auf Ihrem Gerät oder in der AWS CloudShell installiert. Die Version kann mit der Kubernetes-Version Ihres Clusters identisch sein oder bis zu einer Nebenversion älter oder neuer sein. Wenn Ihre Clusterversion beispielsweise `1.29` ist, können Sie `kubectl`-Version `1.28`, `1.29`, oder `1.30` damit verwenden. Informationen zum Installieren oder Aktualisieren von `kubectl` finden Sie unter [`kubectl` und `eksctl` einrichten](install-kubectl.md).
+ Eine vorhandene `kubectl` `config`-Datei, die Ihre Clusterkonfiguration enthält. Informationen zum Erstellen einer `kubectl` `config`-Datei finden Sie unter [kubectl mit einem EKS-Cluster durch Erstellen einer kubeconfig-Datei verbinden](create-kubeconfig.md).

## Erstellen Sie eine Pod Identity-Zuordnung (AWS Konsole)
<a name="pod-id-association-create"></a>

1. Öffnen Sie die [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 **Zugriff** aus.

1. Wählen Sie in den **Pod-Identity-Zuordnungen** die Option **Erstellen** aus.

1. Wählen Sie als **IAM-Rolle** die IAM-Rolle mit den Berechtigungen aus, die die Workload haben soll.
**Anmerkung**  
Die Liste enthält nur Rollen mit der folgenden Vertrauensrichtlinie, die EKS Pod Identity ermöglicht, diese Rollen zu verwenden.

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
               "Effect": "Allow",
               "Principal": {
                   "Service": "pods.eks.amazonaws.com"
               },
               "Action": [
                   "sts:AssumeRole",
                   "sts:TagSession"
               ]
           }
       ]
   }
   ```

    `sts:AssumeRole` – EKS Pod Identity nutzt `AssumeRole`, um die IAM-Rolle anzunehmen, bevor es die temporären Anmeldeinformationen an Ihre Pods übergibt.

    `sts:TagSession`— EKS Pod Identity verwendet`TagSession`, um *Sitzungs-Tags* in die Anfragen an AWS STS aufzunehmen.

   Sie können diese Tags in den *Bedingungsschlüsseln* der Vertrauensrichtlinie verwenden, um einzuschränken, welche Servicekonten, Namespaces und Cluster diese Rolle verwenden dürfen.

   Eine Liste der Amazon EKS-Bedingungsschlüssel finden Sie unter [Bedingungsschlüssel für Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-policy-keys) in der *Service-Autorisierungsreferenz*. Um zu erfahren, mit welchen Aktionen und Ressourcen Sie einen Bedingungsschlüssel verwenden können, lesen Sie von [Amazon Elastic Kubernetes Service definierte Aktionen](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions).

1. Wählen Sie als **Kubernetes-Namespace** den Kubernetes-Namespace aus, der das Servicekonto und die Workload enthält. Optional können Sie den Namen eines Namespace angeben, der nicht im Cluster vorhanden ist.

1. Wählen Sie für das **Kubernetes-Servicekonto** das zu verwendende Kubernetes-Servicekonto aus. Das Manifest für Ihre Kubernetes-Workload muss dieses Servicekonto angeben. Optional können Sie den Namen eines Servicekontos angeben, das nicht im Cluster vorhanden ist.

1. (Optional) Wählen Sie **Sitzungs-Tags deaktivieren** aus, um die Standard-Sitzungs-Tags zu deaktivieren, die Pod Identity automatisch hinzufügt, wenn es die Rolle übernimmt.

1. (Optional) Schalten **Sie „Sitzungsrichtlinie konfigurieren**“ um, um eine IAM-Richtlinie so zu konfigurieren, dass zusätzliche Einschränkungen auf diese Pod-Identity-Zuordnung angewendet werden, die über die in der IAM-Rolle verknüpften IAM-Richtlinie definierten Berechtigungen hinausgehen.
**Anmerkung**  
Eine Sitzungsrichtlinie kann nur angewendet werden, wenn die Einstellung **Sitzungs-Tags deaktivieren aktiviert** ist.

1. (Optional) Wählen Sie für die **Tags** die Option **Tag hinzufügen** aus, um Metadaten in einem Schlüssel-Wert-Paar hinzuzufügen. Diese Tags werden auf die Zuordnung angewendet und können in IAM-Richtlinien verwendet werden.

   Sie können diesen Schritt wiederholen, um mehrere Regionen hinzuzufügen.

1. Wählen Sie **Erstellen** aus.

## Erstellen Sie eine Pod Identity-Zuordnung (AWS CLI)
<a name="create_a_pod_identity_association_shared_aws_cli"></a>

1. Wenn Sie Ihrer IAM-Rolle eine vorhandene IAM-Richtlinie zuordnen möchten, fahren Sie mit dem nächsten Schritt fort.

   Erstellen Sie eine IAM-Richtlinie. Sie können Ihre eigene Richtlinie erstellen oder eine AWS verwaltete Richtlinie kopieren, die bereits einige der benötigten Berechtigungen gewährt, und sie an Ihre spezifischen Anforderungen anpassen. Weitere Informationen finden Sie unter [Erstellen von IAM-Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) im *IAM-Benutzerhandbuch*.

   1. Erstellen Sie eine Datei, die die Berechtigungen für die AWS Dienste enthält, auf die Ihre Pods zugreifen sollen. Eine Liste aller Aktionen für alle AWS Dienste finden Sie in der [Referenz zur Dienstautorisierung](https://docs.aws.amazon.com/service-authorization/latest/reference/).

      Sie können den folgenden Befehl ausführen, um eine Beispiel-Richtliniendatei zu erstellen, die schreibgeschützten Zugriff auf einen Amazon-S3-Bucket gewährt. Sie können optional Konfigurationsinformationen oder ein Bootstrap-Skript in diesem Bucket speichern und die Container in Ihrem Pod können die Datei aus dem Bucket lesen und in Ihre Anwendung laden. Wenn Sie diese Beispielrichtlinie erstellen möchten, kopieren Sie den folgenden Inhalt auf Ihr Gerät. *my-pod-secrets-bucket*Ersetzen Sie es durch Ihren Bucket-Namen und führen Sie den Befehl aus.

      ```
      {
          "Version":"2012-10-17",		 	 	 
          "Statement": [
              {
                  "Effect": "Allow",
                  "Action": "s3:GetObject",
                  "Resource": "arn:aws:s3:::my-pod-secrets-bucket"
              }
          ]
      }
      ```

   1. Erstellen Sie die IAM-Richtlinie.

      ```
      aws iam create-policy --policy-name my-policy --policy-document file://my-policy.json
      ```

1. Erstellen Sie eine IAM-Rolle und ordnen Sie diese einem Kubernetes- Servicekonto zu.

   1. Wenn Sie ein vorhandenes Kubernetes-Servicekonto haben, das eine IAM-Rolle annehmen soll, können Sie diesen Schritt überspringen.

      Erstellen Sie ein Kubernetes-Servicekonto. Kopieren Sie den folgenden Inhalt auf Ihr Gerät. *my-service-account*Ersetzen Sie ihn durch Ihren gewünschten Namen und gegebenenfalls *default* durch einen anderen Namespace. Wenn Sie eine Änderung vornehmen*default*, muss der Namespace bereits existieren.

      ```
      cat >my-service-account.yaml <<EOF
      apiVersion: v1
      kind: ServiceAccount
      metadata:
        name: my-service-account
        namespace: default
      EOF
      kubectl apply -f my-service-account.yaml
      ```

      Führen Sie den folgenden Befehl aus.

      ```
      kubectl apply -f my-service-account.yaml
      ```

   1. Führen Sie den folgenden Befehl aus, um eine Vertrauensrichtlinie für die IAM-Rolle zu erstellen.

      ```
      {
          "Version":"2012-10-17",		 	 	 
          "Statement": [
              {
                  "Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
                  "Effect": "Allow",
                  "Principal": {
                      "Service": "pods.eks.amazonaws.com"
                  },
                  "Action": [
                      "sts:AssumeRole",
                      "sts:TagSession"
                  ]
              }
          ]
      }
      ```

   1. Erstellen Sie die Rolle. Ersetzen Sie *my-role* durch einen Namen für Ihre IAM-Rolle und *my-role-description* durch eine Beschreibung für Ihre Rolle.

      ```
      aws iam create-role --role-name my-role --assume-role-policy-document file://trust-relationship.json --description "my-role-description"
      ```

   1. Hängen Sie eine IAM-Richtlinie an Ihre Rolle an. Ersetzen Sie *my-role* durch den Namen Ihrer IAM-Rolle und *my-policy* durch den Namen einer vorhandenen Richtlinie, die Sie erstellt haben.

      ```
      aws iam attach-role-policy --role-name my-role --policy-arn=arn:aws: iam::111122223333:policy/my-policy
      ```
**Anmerkung**  
Im Gegensatz zu IAM-Rollen für Servicekonten verwendet EKS Pod Identity keine Annotation im Servicekonto.

   1. Führen Sie den folgenden Befehl aus, um die Zuordnung zu erstellen. `my-cluster`Ersetzen Sie es durch den Namen des Clusters, *my-service-account* ersetzen Sie es durch Ihren gewünschten Namen und *default* gegebenenfalls durch einen anderen Namespace.

      ```
      aws eks create-pod-identity-association --cluster-name my-cluster --role-arn arn:aws: iam::111122223333:role/my-role --namespace default --service-account my-service-account
      ```

      Eine Beispielausgabe sieht wie folgt aus.

      ```
      {
          "association": {
              "clusterName": "my-cluster",
              "namespace": "default",
              "serviceAccount": "my-service-account",
              "roleArn": "arn:aws: iam::111122223333:role/my-role",
              "associationArn": "arn:aws::111122223333:podidentityassociation/my-cluster/a-abcdefghijklmnop1",
              "associationId": "a-abcdefghijklmnop1",
              "tags": {},
              "createdAt": 1700862734.922,
              "modifiedAt": 1700862734.922
          }
      }
      ```
**Anmerkung**  
Sie können den Namen eines Namespace und eines Servicekontos angeben, der bzw. das nicht im Cluster vorhanden ist. Sie müssen den Namespace, das Servicekonto und die Workload erstellen, die das Servicekonto verwendet, damit die EKS-Pod-Identity-Zuordnung funktioniert.

## Konfiguration bestätigen
<a name="pod-id-confirm-role-configuration"></a>

1. Stellen Sie sicher, dass die Vertrauensrichtlinie der IAM-Rolle korrekt konfiguriert ist.

   ```
   aws iam get-role --role-name my-role --query Role.AssumeRolePolicyDocument
   ```

   Eine Beispielausgabe sieht wie folgt aus.

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Sid": "Allow EKS Auth service to assume this role for Pod Identities",
               "Effect": "Allow",
               "Principal": {
                   "Service": "pods.eks.amazonaws.com"
               },
               "Action": [
                   "sts:AssumeRole",
                   "sts:TagSession"
               ]
           }
       ]
   }
   ```

1. Stellen Sie sicher, dass die Richtlinie, die Sie in einem vorherigen Schritt an Ihre Rolle angehängt haben, an die Rolle angehängt ist.

   ```
   aws iam list-attached-role-policies --role-name my-role --query 'AttachedPolicies[].PolicyArn' --output text
   ```

   Eine Beispielausgabe sieht wie folgt aus.

   ```
    arn:aws: iam::111122223333:policy/my-policy
   ```

1. Legen Sie eine Variable fest, um den Amazon-Ressourcennamen (ARN) der Richtlinie zu speichern, die Sie verwenden möchten. *my-policy*Ersetzen Sie es durch den Namen der Richtlinie, für die Sie die Berechtigungen bestätigen möchten.

   ```
   export policy_arn=arn:aws: iam::111122223333:policy/my-policy
   ```

1. Zeigen Sie die Standardversion der Richtlinie an.

   ```
   aws iam get-policy --policy-arn $policy_arn
   ```

   Eine Beispielausgabe sieht wie folgt aus.

   ```
   {
       "Policy": {
           "PolicyName": "my-policy",
           "PolicyId": "EXAMPLEBIOWGLDEXAMPLE",
           "Arn": "arn:aws: iam::111122223333:policy/my-policy",
           "Path": "/",
           "DefaultVersionId": "v1",
           [...]
       }
   }
   ```

1. Überprüfen Sie den Inhalt der Richtlinie, um sicherzustellen, dass sie alle Berechtigungen enthält, die Ihr Pod benötigt. Falls erforderlich, ersetzen Sie *1* den folgenden Befehl durch die Version, die in der vorherigen Ausgabe zurückgegeben wurde.

   ```
   aws iam get-policy-version --policy-arn $policy_arn --version-id v1
   ```

   Eine Beispielausgabe sieht wie folgt aus.

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Action": "s3:GetObject",
               "Resource": "arn:aws:s3:::my-pod-secrets-bucket"
           }
       ]
   }
   ```

   Wenn Sie die Beispielrichtlinie in einem vorherigen Schritt erstellt haben, ist Ihre Ausgabe dieselbe. Wenn Sie eine andere Richtlinie erstellt haben, ist der *example* Inhalt anders.

## Nächste Schritte
<a name="_next_steps"></a>

 [Pods für den Zugriff auf AWS Dienste mit Dienstkonten konfigurieren](pod-id-configure-pods.md) 

# Zugreifen auf AWS Ressourcen mithilfe von EKS Pod Identity Target IAM-Rollen
<a name="pod-id-assign-target-role"></a>

Wenn Sie Anwendungen auf Amazon Elastic Kubernetes Service (Amazon EKS) ausführen, müssen Sie möglicherweise auf AWS Ressourcen zugreifen, die in verschiedenen AWS Konten vorhanden sind. In dieser Anleitung erfahren Sie, wie Sie den kontoübergreifenden Zugriff mithilfe von EKS Pod Identity einrichten, sodass Ihre Kubernetes-Pods mithilfe von Zielrollen auf andere AWS Ressourcen zugreifen können.

## Voraussetzungen
<a name="_prerequisites"></a>

Stellen Sie vor dem Beginn sicher, dass Sie die folgenden Schritte abgeschlossen haben:
+  [Einrichtung des Amazon-EKS-Pod-Identity-Agenten](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html) 
+  [Erstellung der EKS-Pod-Identity-Rolle](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) 

## So funktioniert’s
<a name="_how_it_works"></a>

Mit Pod Identity können Anwendungen in Ihrem EKS-Cluster über einen Prozess, der als Rollenverkettung bezeichnet wird, kontenübergreifend auf AWS Ressourcen zugreifen.

Wenn Sie eine Pod Identity-Zuordnung erstellen, können Sie zwei IAM-Rollen angeben: eine [EKS-Pod-Identity-Rolle](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) in demselben Konto wie Ihr EKS-Cluster und eine Ziel-IAM-Rolle aus dem Konto, das Ihre AWS Ressourcen enthält, auf die Sie zugreifen möchten (wie S3-Buckets oder RDS-Datenbanken). Die [EKS-Pod-Identity-Rolle](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) muss sich aufgrund der [ PassRoleIAM-Anforderungen](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_iam-passrole-service.html) im Konto Ihres EKS-Clusters befinden, während sich die Target-IAM-Rolle in jedem Konto befinden kann. AWS PassRole ermöglicht es einer AWS Entität, die Rollenübernahme an einen anderen Dienst zu delegieren. EKS Pod Identity verwendet PassRole , um eine Rolle mit einem Kubernetes-Dienstkonto zu verbinden. Dabei müssen sich sowohl die Rolle als auch die Identität, die sie übergibt, in demselben AWS Konto wie der EKS-Cluster befinden. Wenn Ihr Anwendungs-Pod auf AWS Ressourcen zugreifen muss, fordert er Anmeldeinformationen von Pod Identity an. Pod Identity führt dann automatisch zwei Rollenübernahmen nacheinander durch: Zunächst übernimmt es die [EKS-Pod-Identity-Rolle](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) und verwendet dann diese Anmeldeinformationen, um die Ziel-IAM-Rolle zu übernehmen. Durch diesen Vorgang erhält Ihr Pod temporäre Anmeldeinformationen, für die die in der Zielrolle definierten Berechtigungen gelten, sodass Sie sicher auf Ressourcen in anderen AWS Konten zugreifen können.

## Überlegungen zum Caching
<a name="_caching_considerations"></a>

Aufgrund von Caching-Mechanismen werden Aktualisierungen einer IAM-Rolle in einer vorhandenen Pod-Identity-Zuordnung möglicherweise nicht sofort in den Pods wirksam, die auf Ihrem EKS-Cluster ausgeführt werden. Der Pod-Identity-Agent speichert IAM-Anmeldedaten basierend auf der Konfiguration der Zuordnung zum Zeitpunkt des Abrufs der Anmeldedaten zwischen. Wenn die Zuordnung nur eine [EKS-Pod-Identity-Rolle](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) und keine Ziel-IAM-Rolle enthält, bleiben die im Cache gespeicherten Anmeldedaten 6 Stunden lang gültig. Wenn die Zuordnung sowohl die [EKS-Pod-Identity-Rolle](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) ARN als auch eine Ziel-IAM-Rolle enthält, bleiben die im Cache gespeicherten Anmeldeinformationen 59 Minuten lang gültig. Durch das Ändern einer vorhandenen Zuordnung, z. B. durch Aktualisieren der ARN der [EKS-Pod-Identity-Rolle](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) oder Hinzufügen einer Ziel-IAM-Rolle, wird der vorhandene Cache nicht zurückgesetzt. Daher erkennt der Agent Aktualisierungen erst, wenn die zwischengespeicherten Anmeldedaten aktualisiert werden. Um Änderungen schneller anzuwenden, können Sie die vorhandenen Pods neu erstellen. Andernfalls müssen Sie warten, bis der Cache abgelaufen ist.

## Schritt 1: Erstellen und Zuordnen einer Ziel-IAM-Rolle
<a name="_step_1_create_and_associate_a_target_iam_role"></a>

In diesem Schritt erstellen Sie eine sichere Vertrauenskette, indem Sie eine Ziel-IAM-Rolle erstellen und konfigurieren. Zur Veranschaulichung erstellen wir eine neue Target-IAM-Rolle, um eine Vertrauenskette zwischen zwei AWS Konten einzurichten: Die [EKS-Pod-Identity-Rolle](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) (z. B.`eks-pod-identity-primary-role`) im AWS Konto des EKS-Clusters erhält die Erlaubnis, die Target-IAM-Rolle (z. B.`eks-pod-identity-aws-resources`) in Ihrem Zielkonto zu übernehmen, wodurch der Zugriff auf AWS Ressourcen wie Amazon S3 S3-Buckets ermöglicht wird.

### Ziel-IAM-Rolle erstellen
<a name="_create_the_target_iam_role"></a>

1. Öffnen Sie die [Amazon IAM-Konsole](https://console.aws.amazon.com/iam/home).

1. Vergewissern Sie sich in der oberen Navigationsleiste, dass Sie bei dem Konto angemeldet sind, das die AWS Ressourcen (wie S3-Buckets oder DynamoDB-Tabellen) für Ihre Target IAM-Rolle enthält.

1. Wählen Sie im linken Navigationsbereich **Roles** aus.

1. Wählen Sie die Schaltfläche „**Rolle erstellen**“ und anschließend „** AWS Konto**“ unter „Vertrauenswürdiger Entitätstyp“.

1. Wählen Sie **Anderes AWS Konto**, geben Sie Ihre AWS Kontonummer ein (das Konto, für das Ihre [EKS Pod Identity-Rolle](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) existiert) und wählen Sie dann **Weiter**.

1. **Fügen Sie die Berechtigungsrichtlinien hinzu, die Sie der Rolle zuordnen möchten (z. B. AmazonS3FullAccess), und wählen Sie dann Weiter.**

1. Geben Sie einen Rollennamen ein, z. B. `MyCustomIAMTargetRole`, und wählen Sie dann **Rolle erstellen** aus.

### Aktualisierung der Vertrauensrichtlinie für die Ziel-IAM-Rolle
<a name="_update_the_target_iam_role_trust_policy"></a>

1. Nach der Erstellung der Rolle werden Sie zur Liste **Rollen** zurückgeleitet. Suchen und wählen Sie die neue Rolle aus, die Sie im vorherigen Schritt erstellt haben (z. B. `MyCustomIAMTargetRole`).

1. Wählen Sie den Tab **Vertraunsbeziehungen**.

1. Klicken Sie auf der rechten Seite auf **Vertrauensrichtlinie bearbeiten**.

1. Ersetzen Sie im Richtlinien-Editor die Standard-JSON-Datei durch Ihre Vertrauensrichtlinie. Ersetzen Sie die Platzhalterwerte für den Rollennamen und `111122223333` im ARN der IAM-Rolle durch die AWS Konto-ID, die Ihren EKS-Cluster hostet. Sie können PrincipalTags in der Rollenvertrauensrichtlinie optional auch festlegen, dass nur bestimmte Dienstkonten aus einem bestimmten Cluster und Namespace Ihre Zielrolle übernehmen. Beispiel:

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession"
      ],
      "Condition": {
        "StringEquals": {
          "aws:RequestTag/eks-cluster-arn": "arn:aws:eks:us-east-1:111122223333:cluster/example-cluster",
          "aws:RequestTag/kubernetes-namespace": "ExampleNameSpace",
          "aws:RequestTag/kubernetes-service-account": "ExampleServiceAccountName"
        },
        "ArnEquals": {
          "aws:PrincipalARN": "arn:aws:iam::111122223333:role/eks-pod-identity-primary-role"
        }
      }
    }
  ]
}
```

Mit der obigen Richtlinienrichtlinie kann die Rolle `eks-pod-identeity-primary-role` aus dem AWS Konto 111122223333 mit den entsprechenden [EKS Pod Identity-Sitzungstags](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-abac.html) diese Rolle übernehmen.

Wenn Sie [Sitzungs-Tags in Ihrer EKS-Pod-Identität deaktiviert](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-abac.html#pod-id-abac-tags) haben, legt die EKS Pod Identity beim Übernehmen einer Ziel-Rolle auch die `sts:ExternalId` mit Informationen zum Cluster, Namespace und Servicekonto eines Pods fest.

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "region/111122223333/cluster-name/namespace/service-account-name"
        },
        "ArnEquals": {
          "aws:PrincipalARN": "arn:aws:iam::111122223333:role/eks-pod-identity-primary-role"
        }
      }
    },
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": "sts:TagSession"
    }
  ]
}
```

Die oben genannte Richtlinie trägt dazu bei, dass nur der erwartete Cluster, Namespace und das Servicekonto die Zielrolle übernehmen können.

### Aktualisierung der Berechtigungsrichtlinie für die EKS-Pod-Identity-Rolle
<a name="_update_the_permission_policy_for_eks_pod_identity_role"></a>

In diesem Schritt aktualisieren Sie die Berechtigungsrichtlinie der [EKS-Pod-Identity-Rolle](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html), die Ihrem Amazon-EKS-Cluster zugeordnet ist, indem Sie die Ziel-IAM-Rolle ARN als Ressource hinzufügen.

1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).

1. Wählen Sie im linken Navigationsbereich **Cluster** und anschließend den Namen des EKS-Clusters, den Sie ändern möchten.

1. Wählen Sie die Registerkarte **Zugriff** aus.

1. Wählen Sie unter **Pod Identity-Zuordnungen** Ihre [EKS-Pod-Identity-Rolle](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) aus.

1. Wählen Sie **Berechtigungen**, **Berechtigungen hinzufügen** und anschließend **Inline-Richtlinie erstellen** aus.

1. Wählen Sie auf der rechten Seite **JSON** aus.

1. Ersetzen Sie im Richtlinien-Editor die Standard-JSON-Datei durch Ihre Berechtigungsrichtlinie. Ersetzen Sie den Platzhalterwert für den Rollennamen und `222233334444` in der IAM-Rolle ARN durch Ihre Ziel-IAM-Rolle. Beispiel:

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession"
            ],
            "Resource": "arn:aws:iam::222233334444:role/eks-pod-identity-aws-resources"
        }
    ]
}
```

## Schritt 2: Zuordnung der Ziel-IAM-Rolle zu einem Kubernetes-Servicekonto
<a name="_step_2_associate_the_target_iam_role_to_a_kubernetes_service_account"></a>

In diesem Schritt erstellen Sie eine Zuordnung zwischen der Ziel-IAM-Rolle und dem Kubernetes-Servicekonto in Ihrem EKS-Cluster.

1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).

1. Wählen Sie im linken Navigationsbereich **Cluster** und anschließend den Namen des Clusters aus, zu dem Sie die Zuordnung hinzufügen möchten.

1. Wählen Sie die Registerkarte **Zugriff** aus.

1. Wählen Sie in den **Pod-Identity-Zuordnungen** die Option **Erstellen** aus.

1. Wählen Sie die [EKS-Pod-Identity-Rolle](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) in der **IAM-Rolle** für Ihre Workloads aus.

1. Wählen Sie die Ziel-IAM-Rolle in der **Ziel-IAM-Rolle** aus, die von der [EKS-Pod-Identity-Rolle](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) übernommen werden soll.

1. Geben Sie im Feld **Kubernetes-Namespace** den Namen des Namespace ein, in dem Sie die Zuordnung erstellen möchten (z. B. `my-app-namespace`). Dies definiert, wo sich das Servicekonto befindet.

1. Geben Sie im Feld **Kubernetes-Servicekonto** den Namen des Servicekontos ein (z. B. `my-service-account`), das die IAM-Anmeldeinformationen verwenden soll. Dadurch wird die IAM-Rolle dem Servicekonto zugeordnet.

1. (Optional) Wählen Sie **Sitzungs-Tags deaktivieren** aus, um die Standardsitzungs-Tags zu deaktivieren, die Pod Identity automatisch hinzufügt, wenn es die Rolle übernimmt.

1. (Optional) Schalten **Sie „Sitzungsrichtlinie konfigurieren**“ um, um eine IAM-Richtlinie so zu konfigurieren, dass zusätzliche Einschränkungen auf diese Pod-Identity-Zuordnung angewendet werden, die über die Berechtigungen hinausgehen, die in der IAM-Richtlinie für die **Ziel-IAM-Rolle** definiert sind.
**Anmerkung**  
1. Eine Sitzungsrichtlinie kann nur angewendet werden, wenn die Einstellung **Sitzungs-Tags deaktivieren aktiviert** ist. 2. Wenn Sie eine Sitzungsrichtlinie angeben, gelten die Richtlinieneinschränkungen für die Berechtigungen der **Target-IAM-Rolle** und nicht für die **IAM-Rolle**, die dieser Pod-Identity-Zuordnung zugeordnet ist.

1. Wählen Sie **Erstellen** aus, um die Zuordnung zu erstellen.

# Pods für den Zugriff auf AWS Dienste mit Dienstkonten konfigurieren
<a name="pod-id-configure-pods"></a>

Wenn ein Pod auf AWS Dienste zugreifen muss, müssen Sie ihn für die Verwendung eines Kubernetes-Dienstkontos konfigurieren. Das Dienstkonto muss einer AWS Identity and Access Management (IAM) -Rolle zugeordnet sein, die über Berechtigungen für den Zugriff auf die AWS Dienste verfügt.
+ Einen vorhandenen -Cluster. Wenn Sie keine Rolle haben, können Sie sie mithilfe einer der Anleitungen in [Erste Schritte mit Amazon EKS](getting-started.md) erstellen.
+ Ein vorhandenes Kubernetes-Servicekonto und eine EKS-Pod-Identity-Zuordnung, die das Servicekonto einer IAM-Rolle zuordnet. Der Rolle muss eine IAM-Richtlinie zugeordnet sein, die die Berechtigungen enthält, die Ihre Pods für die Nutzung AWS von Diensten haben sollen. Weitere Informationen zu Rollen, ihren Vorteilen sowie zu ihrer Erstellung und Konfiguration finden Sie unter [Zuordnung einer IAM-Rolle einem Kubernetes-Servicekonto](pod-id-association.md).
+ Die neueste Version der AWS CLI, die auf Ihrem Gerät installiert und konfiguriert ist, oder AWS CloudShell. Sie können Ihre aktuelle Version mit `aws --version | cut -d / -f2 | cut -d ' ' -f1` überprüfen. Paketmanager wie `yum``apt-get`, oder Homebrew für macOS liegen oft mehrere Versionen hinter der neuesten Version der AWS CLI. Informationen zur Installation der neuesten Version finden Sie unter [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) und [Schnellkonfiguration mit aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) im Benutzerhandbuch für die AWS Befehlszeilenschnittstelle. Die in der installierte AWS CLI-Version AWS CloudShell kann auch mehrere Versionen hinter der neuesten Version liegen. Informationen zur Aktualisierung finden Sie im AWS CloudShell Benutzerhandbuch unter [AWS CLI in Ihrem Home-Verzeichnis installieren](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software).
+ Das `kubectl`-Befehlszeilen-Tool ist auf Ihrem Gerät oder in der AWS CloudShell installiert. Die Version kann mit der Kubernetes-Version Ihres Clusters identisch sein oder bis zu einer Nebenversion älter oder neuer sein. Wenn Ihre Clusterversion beispielsweise `1.29` ist, können Sie `kubectl`-Version `1.28`, `1.29`, oder `1.30` damit verwenden. Informationen zum Installieren oder Aktualisieren von `kubectl` finden Sie unter [`kubectl` und `eksctl` einrichten](install-kubectl.md).
+ Eine vorhandene `kubectl` `config`-Datei, die Ihre Clusterkonfiguration enthält. Informationen zum Erstellen einer `kubectl` `config`-Datei finden Sie unter [kubectl mit einem EKS-Cluster durch Erstellen einer kubeconfig-Datei verbinden](create-kubeconfig.md).

  1. Verwenden Sie den folgenden Befehl, um ein Bereitstellungs-Manifest zu erstellen, mit dem Sie einen Pod bereitstellen können, um die Konfiguration zu bestätigen. Ersetzen Sie die Beispielwerte durch eigene Werte.

     ```
     cat >my-deployment.yaml <<EOF
     apiVersion: apps/v1
     kind: Deployment
     metadata:
       name: my-app
     spec:
       selector:
         matchLabels:
           app: my-app
       template:
         metadata:
           labels:
             app: my-app
         spec:
           serviceAccountName: my-service-account
           containers:
           - name: my-app
             image: public.ecr.aws/nginx/nginx:X.XX
     EOF
     ```

  1. Stellen Sie das Manifest in Ihrem Cluster bereit.

     ```
     kubectl apply -f my-deployment.yaml
     ```

  1. Vergewissern Sie sich, dass die erforderlichen Umgebungsvariablen für Ihren Pod vorhanden sind.

     1. Zeigen Sie die Pods an, die im vorherigen Schritt bereitgestellt wurden.

        ```
        kubectl get pods | grep my-app
        ```

        Eine Beispielausgabe sieht wie folgt aus.

        ```
        my-app-6f4dfff6cb-76cv9   1/1     Running   0          3m28s
        ```

     1. Vergewissern Sie sich, dass der Pod eine Token-Datei-Einbindung für ein Servicekonto hat.

        ```
        kubectl describe pod my-app-6f4dfff6cb-76cv9 | grep AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE:
        ```

        Eine Beispielausgabe sieht wie folgt aus.

        ```
        AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE:  /var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token
        ```

  1. Vergewissern Sie sich, dass Ihre Pods mithilfe der Berechtigungen, die Sie in der Ihrer Rolle beigefügten IAM-Richtlinie zugewiesen haben, mit den AWS Diensten interagieren können.
**Anmerkung**  
Wenn ein Pod AWS Anmeldeinformationen von einer IAM-Rolle verwendet, die mit einem Dienstkonto verknüpft ist, verwendet die AWS CLI oder andere SDKs in den Containern für diesen Pod die Anmeldeinformationen, die von dieser Rolle bereitgestellt werden. Der Pod hat weiterhin Zugriff auf die der [Amazon-EKS-Knoten-IAM-Rolle](create-node-role.md) bereitgestellten Anmeldeinformationen, es sei denn, Sie beschränken den Zugriff auf diese Anmeldeinformationen. Weitere Informationen finden Sie unter [Beschränken Sie den Zugriff auf das Instance-Profil, das dem Worker-Knoten zugewiesen ist](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node).

     Wenn Ihre Pods nicht wie erwartet mit den Services interagieren können, führen Sie die folgenden Schritte aus, um sicherzustellen, dass alles richtig konfiguriert ist.

     1. Vergewissern Sie sich, dass Ihre Pods eine AWS SDK-Version verwenden, die die Übernahme einer IAM-Rolle über eine EKS-Pod-Identity-Zuordnung unterstützt. Weitere Informationen finden Sie unter [Verwendung der Pod Identity mit dem AWS-SDK](pod-id-minimum-sdk.md).

     1. Stellen Sie sicher, dass die Bereitstellung das Servicekonto verwendet.

        ```
        kubectl describe deployment my-app | grep "Service Account"
        ```

        Eine Beispielausgabe sieht wie folgt aus.

        ```
        Service Account:  my-service-account
        ```

# Pods Zugriff auf AWS Ressourcen basierend auf Tags gewähren
<a name="pod-id-abac"></a>

Die attributbasierte Zugriffskontrolle (ABAC) gewährt Benutzern Rechte anhand von Richtlinien, die Attribute miteinander kombinieren. EKS Pod Identity fügt den temporären Anmeldeinformationen für jeden Pod Tags mit Attributen wie Cluster-Name, Namespace und Servicekonto-Name hinzu. Diese Rollensitzungs-Tags ermöglichen es Administratoren, eine einzelne Rolle zu erstellen, die für alle Dienstkonten verwendet werden kann, indem sie den Zugriff auf AWS Ressourcen auf der Grundlage übereinstimmender Tags ermöglicht. Durch den zusätzlichen Support für Rollensitzungs-Tags können Kunden engere Sicherheitsgrenzen zwischen Clustern und Workloads innerhalb von Clustern durchsetzen und gleichzeitig dieselben IAM-Rollen und IAM-Richtlinien wiederverwenden.

## Beispiel-Richtlinie mit Tags
<a name="_sample_policy_with_tags"></a>

Nachfolgend finden Sie ein Beispiel für eine IAM-Richtlinie, die `s3:GetObject`-Berechtigungen gewährt, wenn das entsprechende Objekt mit dem EKS-Clusternamen gekennzeichnet ist.

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:GetObjectTagging"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "s3:ExistingObjectTag/eks-cluster-name": "${aws:PrincipalTag/eks-cluster-name}"
                }
            }
        }
    ]
}
```

## Aktivieren oder Deaktivieren von Sitzungs-Tags
<a name="pod-id-abac-tags"></a>

EKS Pod Identity fügt einen vordefinierten Satz von Sitzungs-Tags hinzu, wenn es die Rolle übernimmt. Diese Sitzungs-Tags ermöglichen es Administratoren, eine einzelne Rolle zu erstellen, die ressourcenübergreifend verwendet werden kann, indem sie den Zugriff auf AWS Ressourcen auf der Grundlage übereinstimmender Tags ermöglicht.

### Aktivieren von Sitzungs-Tags
<a name="_enable_session_tags"></a>

Sitzungstags werden automatisch mit EKS Pod Identity aktiviert – Ihrerseits sind keine Maßnahmen erforderlich. Standardmäßig fügt EKS Pod Identity Ihrer Sitzung eine Reihe vordefinierter Tags hinzu. Um in Richtlinien auf diese Tags zu verweisen, verwenden Sie die Syntax `${aws:PrincipalTag/` gefolgt vom Tag-Schlüssel. Beispiel, `${aws:PrincipalTag/kubernetes-namespace}`.
+  `eks-cluster-arn` 
+  `eks-cluster-name` 
+  `kubernetes-namespace` 
+  `kubernetes-service-account` 
+  `kubernetes-pod-name` 
+  `kubernetes-pod-uid` 

### Deaktivieren von Sitzungs-Tags
<a name="_disable_session_tags"></a>

 AWS komprimiert Inline-Sitzungsrichtlinien, verwaltete Richtlinien ARNs und Sitzungs-Tags in ein gepacktes Binärformat mit separatem Limit. Wenn Sie einen `PackedPolicyTooLarge`-Fehler erhalten, die darauf hinweist, dass das gepackte Binärformat die Größenbeschränkung überschritten hat, können Sie diese Größe reduzieren, indem Sie die von EKS Pod Identity hinzugefügten Sitzungs-Tags deaktivieren. Um diese Sitzungs-Tags zu deaktivieren, führen Sie die folgenden Schritte aus:

1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).

1. Wählen Sie im linken Navigationsbereich **Clusters** und anschließend den Namen des Clusters, den Sie ändern möchten.

1. Wählen Sie die Registerkarte **Zugriff** aus.

1. Wählen Sie unter **Pod-Identity-Zuordnungen** die **Zuordnungs-ID**, die Sie ändern möchten, und klicken Sie dann auf **Bearbeiten**.

1. Wählen Sie unter **Sitzungs-Tags** die Option **Sitzungs-Tags deaktivieren**.

1. Wählen Sie **Änderungen speichern ** aus.

## Kontoübergreifende Tags
<a name="pod-id-abac-chaining"></a>

Alle Sitzungs-Tags, die von EKS Pod Identity hinzugefügt werden, sind *transitiv*. Die Tag-Schlüssel und -Werte werden an alle `AssumeRole`-Aktionen weitergegeben, die Ihre Workloads verwenden, um Rollen auf ein anderes Konto zu wechseln. Sie können diese Tags in Richtlinien in anderen Konten verwenden, um den Zugriff in kontoübergreifenden Szenarien einzuschränken. Weitere Informationen finden Sie im *IAM-Benutzerhandbuch* unter [Verketten von Rollen mit Sitzungs-Tags](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html#id_session-tags_role-chaining).

## Benutzerdefinierte Tags
<a name="pod-id-abac-custom-tags"></a>

EKS Pod Identity kann der `AssumeRole`-Aktion, die es ausführt, keine zusätzlichen benutzerdefinierten Tags hinzufügen. Tags, die Sie auf die IAM-Rolle anwenden, sind jedoch immer im gleichen Format verfügbar: `${aws:PrincipalTag/` gefolgt vom Schlüssel, zum Beispiel `${aws:PrincipalTag/MyCustomTag}`.

**Anmerkung**  
Tags, die der Sitzung über die `sts:AssumeRole`-Anfrage hinzugefügt wurden, haben im Konfliktfall Vorrang. Nehmen wir zum Beispiel an:  
Amazon EKS fügt der Sitzung einen Schlüssel `eks-cluster-name` und einen Wert `my-cluster` hinzu, wenn EKS die Kundenrolle übernimmt und
Sie fügen der IAM-Rolle ein `eks-cluster-name`-Tag mit dem Wert `my-own-cluster` hinzu.
In diesem Fall hat Ersteres Vorrang und der Wert für das `eks-cluster-name`-Tag ist `my-cluster`.

# Verwendung der Pod Identity mit dem AWS-SDK
<a name="pod-id-minimum-sdk"></a>

## Verwenden von EKS-Pod-Identity-Anmeldeinformationen
<a name="pod-id-using-creds"></a>

Um die Anmeldeinformationen von einer EKS-Pod-Identity-Zuordnung zu nutzen, kann Ihr Code ein beliebiges AWS-SDK verwenden, um einen Client für einen AWS-Service mit einem SDK zu erstellen. Standardmäßig sucht das SDK in einer Kette von Speicherorten nach zu verwendenden Anmeldeinformationen für die AWS-Identitäts- und Zugriffsverwaltung. Die Anmeldeinformationen für EKS Pod Identity werden verwendet, wenn Sie bei der Erstellung des Clients keinen Anmeldeinformationsanbieter angeben oder Sie das SDK anderweitig initialisiert haben.

Das funktioniert, weil EKS-Pod-Identitäten dem *Anbieter für Container-Anmeldeinformationen* hinzugefügt wurden, der in einem Schritt in der standardmäßigen Anmeldeinformationskette durchsucht wird. Wenn Ihre Workloads derzeit Anmeldeinformationen verwenden, die in der Kette der Anmeldeinformationen weiter vorn stehen, werden diese Anmeldeinformationen auch dann weiter verwendet, wenn Sie eine EKS-Pod-Identity-Zuordnung für dieselbe Workload konfigurieren.

Weitere Informationen zur Funktionsweise von EKS-Pod-Identitäten finden Sie unter [Funktionsweise von EKS Pod Identity verstehen](pod-id-how-it-works.md).

Bei der Verwendung von [Erfahren Sie, wie EKS Pod Identity Pods Zugriff auf AWS-Services gewährt](pod-identities.md) müssen die Container in Ihren Pods eine AWS-SDK-Version verwenden, welche die Übernahme einer IAM-Rolle vom EKS-Pod-Identity-Agent unterstützt. Stellen Sie sicher, dass Sie die folgenden Versionen oder höher für Ihr AWS-SDK verwenden:
+ Java (Version 2) – [2.21.30](https://github.com/aws/aws-sdk-java-v2/releases/tag/2.21.30) 
+ Java – [1.12.746](https://github.com/aws/aws-sdk-java/releases/tag/1.12.746) 
+ Go v1 – [v1.47.11](https://github.com/aws/aws-sdk-go/releases/tag/v1.47.11) 
+ Go v2 – [release-2023-11-14](https://github.com/aws/aws-sdk-go-v2/releases/tag/release-2023-11-14) 
+ Python (Boto3) – [1.34.41](https://github.com/boto/boto3/releases/tag/1.34.41) 
+ Python (botocore) – [1.34.41](https://github.com/boto/botocore/releases/tag/1.34.41) 
+  AWS-CLI – [1.30.0](https://github.com/aws/aws-cli/releases/tag/1.30.0) 

   AWS-CLI – [2.15.0](https://github.com/aws/aws-cli/releases/tag/2.15.0) 
+ JavaScript v2 – [2.1550.0](https://github.com/aws/aws-sdk-js/releases/tag/v2.1550.0) 
+ JavaScript v3 – [v3.458.0](https://github.com/aws/aws-sdk-js-v3/releases/tag/v3.458.0) 
+ Kotlin – [v1.0.1](https://github.com/awslabs/aws-sdk-kotlin/releases/tag/v1.0.1) 
+ Ruby – [3.188.0](https://github.com/aws/aws-sdk-ruby/blob/version-3/gems/aws-sdk-core/CHANGELOG.md#31880-2023-11-22) 
+ Rust – [release-2024-03-13](https://github.com/awslabs/aws-sdk-rust/releases/tag/release-2024-03-13) 
+ C\$1\$1 – [1.11.263](https://github.com/aws/aws-sdk-cpp/releases/tag/1.11.263) 
+ .NET – [3.7.734.0](https://github.com/aws/aws-sdk-net/releases/tag/3.7.734.0) 
+ PowerShell – [4.1.502](https://www.powershellgallery.com/packages/AWS.Tools.Common/4.1.502) 
+ PHP – [3.289.0](https://github.com/aws/aws-sdk-php/releases/tag/3.287.1) 

Um sicherzustellen, dass Sie ein unterstütztes SDK verwenden, befolgen Sie die Installationsanweisungen für Ihr bevorzugtes SDK unter [Tools für die Entwickelung in AWS](https://aws.amazon.com/tools/), wenn Sie Ihre Container entwickeln.

Eine Liste der Add-Ons, die EKS Pod Identity unterstützen, finden Sie unter [Unterstützungsreferenz für Pod Identity](retreive-iam-info.md#pod-id-add-on-versions).

# Deaktivierung von `IPv6` im EKS-Pod-Identity-Agent
<a name="pod-id-agent-config-ipv6"></a>

## AWS-Managementkonsole
<a name="pod-id-console"></a>

1. Um `IPv6` im EKS-Pod-Identity-Agent zu deaktivieren, fügen Sie die folgende Konfiguration zu den **Optionalen Konfigurationseinstellungen** des EKS- Add-Ons hinzu.

   1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).

   1. Wählen Sie im linken Navigationsbereich **Clusters** (Cluster) aus. Wählen Sie anschließend den Namen des Clusters aus, für den Sie das Add-On konfigurieren möchten.

   1. Wählen Sie die Registerkarte **Add-ons**.

   1. Aktivieren Sie das Kontrollkästchen oben rechts im Feld „EKS-Pod-Identity-Agent-Add-on“ und wählen Sie anschließend **Bearbeiten**.

   1. Auf der Seite **EKS-Pod-Identity-Agent konfigurieren**:

      1. Wählen Sie die **Version** aus, die Sie verwenden möchten. Wir empfehlen Ihnen, die gleiche Version wie im vorherigen Schritt beizubehalten und die Version und Konfiguration in separaten Schritten zu aktualisieren.

      1. Erweitern Sie **Optionale Konfigurationseinstellungen**.

      1. Geben Sie den JSON-Schlüssel `"agent":` und den Wert eines verschachtelten JSON-Objekts mit einem Schlüssel `"additionalArgs":` in den **Konfigurationswerten** ein. Der resultierende Text muss ein gültiges JSON-Objekt sein. Wenn dieser Schlüssel und dieser Wert die einzigen Daten im Textfeld sind, setzen Sie den Schlüssel und den Wert in geschweifte Klammern `{ }`. Das folgende Beispiel veranschaulicht, dass die Netzwerkrichtlinie aktiviert ist:

         ```
         {
             "agent": {
                 "additionalArgs": {
                     "-b": "169.254.170.23"
                 }
             }
         }
         ```

         Diese Konfiguration legt die `IPv4`-Adresse als einzige Adresse fest, die vom Agenten verwendet wird.

   1. Um die neue Konfiguration durch Ersetzen des Agent-Pods von EKS Pod Identity anzuwenden, wählen Sie **Änderungen speichern**.

      Amazon EKS wendet Änderungen an den EKS-Add-Ons an, indem es einen *Einführung* von Kubernetes `DaemonSet` für EKS Pod Identity Agent durchführt. Sie können den Status der Einführung im **Aktualisierungsverlauf** des Add-Ons in AWS-Managementkonsole und mit `kubectl rollout status daemonset/eks-pod-identity-agent --namespace kube-system` verfolgen.

       `kubectl rollout` verfügt über die folgenden Befehle:

      ```
      $ kubectl rollout
      
      history  -- View rollout history
      pause    -- Mark the provided resource as paused
      restart  -- Restart a resource
      resume   -- Resume a paused resource
      status   -- Show the status of the rollout
      undo     -- Undo a previous rollout
      ```

      Wenn die Einführung zu lange dauert, macht Amazon EKS die Einführung rückgängig und eine Nachricht mit dem Typ der **Add-On-Aktualisierung** und dem Status **Fehlgeschlagen** dem **Aktualisierungsverlauf** des Add-Ons hinzugefügt. Um etwaige Probleme zu untersuchen, beginnen Sie mit dem Verlauf der Einführung und führen Sie `kubectl logs` auf einem Agent-Pod von EKS Pod Identity aus, um die Protokolle des EKS-Pod-Identity-Agent anzuzeigen.

1. Wenn der neue Eintrag im **Aktualisierungsverlauf** den Status **Erfolgreich** aufweist, ist die Einführung abgeschlossen und das Add-On verwendet die neue Konfiguration in allen Pods von EKS Pod Identity Agent.

## AWS-CLI
<a name="pod-id-cli"></a>

1. Um `IPv6` im EKS-Pod-Identity-Agent zu deaktivieren, fügen Sie die folgende Konfiguration zu den **Konfigurationswerten** des EKS-Add-Ons hinzu.

   Führen Sie den folgenden AWS-CLI-Befehl aus. Ersetzen Sie `my-cluster` durch den Namen Ihres Clusters und den IAM-Rollen-ARN durch die Rolle, die Sie verwenden.

   ```
   aws eks update-addon --cluster-name my-cluster --addon-name eks-pod-identity-agent \
       --resolve-conflicts PRESERVE --configuration-values '{"agent":{"additionalArgs": { "-b": "169.254.170.23"}}}'
   ```

   Diese Konfiguration legt die `IPv4`-Adresse als einzige Adresse fest, die vom Agenten verwendet wird.

   Amazon EKS wendet Änderungen an den EKS-Add-Ons an, indem es eine *Einführung* von Kubernetes DaemonSet für EKS-Pod-Identity-Agent durchführt. Sie können den Status der Einführung im **Aktualisierungsverlauf** des Add-Ons in AWS-Managementkonsole und mit `kubectl rollout status daemonset/eks-pod-identity-agent --namespace kube-system` verfolgen.

    `kubectl rollout` verfügt über die folgenden Befehle:

   ```
   kubectl rollout
   
   history  -- View rollout history
   pause    -- Mark the provided resource as paused
   restart  -- Restart a resource
   resume   -- Resume a paused resource
   status   -- Show the status of the rollout
   undo     -- Undo a previous rollout
   ```

   Wenn die Einführung zu lange dauert, macht Amazon EKS die Einführung rückgängig und eine Nachricht mit dem Typ der **Add-On-Aktualisierung** und dem Status **Fehlgeschlagen** dem **Aktualisierungsverlauf** des Add-Ons hinzugefügt. Um etwaige Probleme zu untersuchen, beginnen Sie mit dem Verlauf der Einführung und führen Sie `kubectl logs` auf einem Agent-Pod von EKS Pod Identity aus, um die Protokolle des EKS-Pod-Identity-Agent anzuzeigen.

# Erstellen einer IAM-Rolle mit der von EKS Pod Identity geforderten Vertrauensrichtlinie
<a name="pod-id-role"></a>

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
            "Effect": "Allow",
            "Principal": {
                "Service": "pods.eks.amazonaws.com"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession"
            ]
        }
    ]
}
```

 ** `sts:AssumeRole` **   
EKS Pod Identity nutzt `AssumeRole`, um die IAM-Rolle anzunehmen, bevor es die temporären Anmeldeinformationen an Ihre Pods übergibt.

 ** `sts:TagSession` **   
EKS Pod Identity verwendet`TagSession`, um *Sitzungs-Tags* in die Anfragen an STS aufzunehmen. AWS 

 **Einstellungsbedingungen**   
Sie können diese Tags in den *Bedingungsschlüsseln* der Vertrauensrichtlinie verwenden, um einzuschränken, welche Servicekonten, Namespaces und Cluster diese Rolle verwenden dürfen. Die Liste der von Pod Identity hinzugefügten Anforderungs-Tags finden Sie unter [Aktivieren oder Deaktivieren von Sitzungs-Tags](pod-id-abac.md#pod-id-abac-tags).  
Sie können beispielsweise mit der folgenden Vertrauensrichtlinie mit dem hinzugefügten `Condition` einschränken, welche Pods die Rolle einer Pod-Identity-IAM-Rolle auf ein bestimmtes `ServiceAccount` und `Namespace` übernehmen können:

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
            "Effect": "Allow",
            "Principal": {
                "Service": "pods.eks.amazonaws.com"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:RequestTag/kubernetes-namespace": [
                        "Namespace"
                    ],
                    "aws:RequestTag/kubernetes-service-account": [
                        "ServiceAccount"
                    ]
                }
            }
        }
    ]
}
```

Eine Liste der Amazon EKS-Bedingungsschlüssel finden Sie unter [Bedingungsschlüssel für Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-policy-keys) in der *Service-Autorisierungsreferenz*. Um zu erfahren, mit welchen Aktionen und Ressourcen Sie einen Bedingungsschlüssel verwenden können, lesen Sie von [Amazon Elastic Kubernetes Service definierte Aktionen](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions).