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.
# Verwenden Sie AWS Secrets and Configuration Provider CSI mit Pod Identity für Amazon EKS
Die AWS Secrets and Configuration Provider-Integration mit dem Pod Identity Agent für Amazon Elastic Kubernetes Service bietet verbesserte Sicherheit, vereinfachte Konfiguration und verbesserte Leistung für Anwendungen, die auf Amazon EKS ausgeführt werden. Pod Identity vereinfacht die IAM-Authentifizierung für Amazon EKS beim Abrufen von Geheimnissen aus Secrets Manager oder Parametern aus dem AWS Systems Manager Parameter Store.
Amazon EKS Pod Identity optimiert die Konfiguration von IAM-Berechtigungen für Kubernetes-Anwendungen, da Berechtigungen direkt über Amazon-EKS-Schnittstellen eingerichtet werden können. Das reduziert die Anzahl der Schritte und der Wechsel zwischen Amazon EKS und IAM-Services entfällt. Pod Identity ermöglicht die Verwendung einer einzigen IAM-Rolle in mehreren Clustern, ohne dass die Vertrauensrichtlinien aktualisiert werden müssen, und unterstützt [Rollensitzungs-Tags](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-abac.html#pod-id-abac-tags) für eine detailliertere Zugriffskontrolle. Dieser Ansatz vereinfacht nicht nur die Richtlinienverwaltung, indem er die rollenübergreifende Wiederverwendung von Berechtigungsrichtlinien ermöglicht, sondern erhöht auch die Sicherheit, indem der Zugriff auf AWS Ressourcen auf der Grundlage übereinstimmender Tags ermöglicht wird.
## Funktionsweise
1. Pod Identity weist dem Pod eine IAM-Rolle zu.
1. ASCP verwendet diese Rolle zur Authentifizierung bei. AWS-Services
1. Falls autorisiert, ruft ASCP die angeforderten Geheimnisse ab und stellt sie dem Pod zur Verfügung.
Weitere Informationen finden Sie im *Benutzerhandbuch für Amazon EKS* unter [Funktionsweise von Amazon EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-how-it-works.html).
## Voraussetzungen
**Wichtig**
Pod Identity wird nur für Amazon EKS in der Cloud unterstützt. Es wird nicht für [Amazon EKS Anywhere](https://aws.amazon.com/eks/eks-anywhere/), [Red Hat OpenShift Service in AWS](https://aws.amazon.com/rosa/) oder selbstverwaltete Kubernetes-Cluster auf Amazon-EC2-Instances unterstützt.
+ Amazon-EKS-Cluster (Version 1.24 oder höher)
+ Zugriff auf AWS CLI einen Amazon EKS-Cluster über `kubectl`
+ Zugriff auf zwei AWS-Konten (für kontoübergreifenden Zugriff)
## Installieren des Pod-Identity-Agents für Amazon EKS
Um Pod Identity in Ihrem Cluster zu verwenden, müssen Sie das Add-on „Amazon EKS Pod Identity Agent“ installieren.
**Installieren des Pod-Identity-Agents**
+ Installieren Sie das Pod Identity Agent-Add-on auf Ihrem Cluster:
```
eksctl create addon \
--name eks-pod-identity-agent \
--cluster clusterName \
--region region
```
## Einrichten von ASCP mit Pod Identity
1. Erstellen Sie eine Berechtigungsrichtlinie, die Zugriff auf die Geheimnisse gewährt`secretsmanager:GetSecretValue`, auf die der Pod zugreifen muss. `secretsmanager:DescribeSecret` Eine Beispielrichtlinie finden Sie unter [Beispiel: Erlaubnis, einzelne Geheimnisse zu lesen und zu beschreiben](auth-and-access_iam-policies.md#auth-and-access_examples-read-and-describe).
1. Erstellen Sie eine IAM-Rolle, die vom Amazon-EKS-Service-Prinzipalen für Pod Identity übernommen werden kann:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
------
Hängen Sie die IAM-Richtlinie an die Rolle an:
```
aws iam attach-role-policy \
--role-name MY_ROLE \
--policy-arn POLICY_ARN
```
1. Erstellen Sie eine Pod-Identity-Zuordnung. Ein Beispiel finden Sie unter [Erstellen einer Pod-Identity-Zuordnung](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-association.html#pod-id-association-create) im *Benutzerhandbuch für Amazon EKS*
1. Erstellen Sie das`SecretProviderClass`, das festlegt, welche Geheimnisse im Pod bereitgestellt werden sollen:
```
kubectl apply -f https://raw.githubusercontent.com/aws/secrets-store-csi-driver-provider-aws/main/examples/ExampleSecretProviderClass-PodIdentity.yaml
```
Der Hauptunterschied in `SecretProviderClass` zwischen IRSA und Pod Identity ist der optionale Parameter `usePodIdentity`. Es ist ein optionales Feld, das den Authentifizierungsansatz bestimmt. Wenn nicht angegeben, wird standardmäßig IAM Roles for Service Accounts (IRSA) verwendet.
+ Verwenden Sie einen der folgenden Werte, um EKS Pod Identity zu verwenden: `"true", "True", "TRUE", "t", "T"`.
+ Wenn Sie explizit IRSA nutzen möchten, verwenden Sie einen der folgenden Werte: `"false", "False", "FALSE", "f", or "F"`.
1. Stellen Sie den Pod, der die Secrets mountet, bereit unter`/mnt/secrets-store`:
```
kubectl apply -f https://raw.githubusercontent.com/aws/secrets-store-csi-driver-provider-aws/main/examples/ExampleDeployment-PodIdentity.yaml
```
1. Wenn Sie einen privaten Amazon EKS-Cluster verwenden, stellen Sie sicher, dass die VPC, in der sich der Cluster befindet, über einen AWS STS Endpunkt verfügt. Weitere Informationen zum Erstellen eines Endpunktes finden Sie unter [Schnittstellen-VPC-Endpunkte](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_interface_vpc_endpoints.html) im *Benutzerhandbuch für AWS Identity and Access Management *.
### Überprüfen des Secret-Mountings
Führen Sie den folgenden Befehl aus, um zu überprüfen, ob der geheime Schlüssel ordnungsgemäß bereitgestellt wurde:
```
kubectl exec -it $(kubectl get pods | awk '/pod-identity-deployment/{print $1}' | head -1) -- cat /mnt/secrets-store/MySecret
```
**So richten Sie Amazon EKS Pod Identity für den Zugriff auf Secrets Manager ein**
1. Erstellen Sie eine Berechtigungsrichtlinie, die Zugriff auf die Geheimnisse gewährt`secretsmanager:GetSecretValue`, auf die der Pod zugreifen muss. `secretsmanager:DescribeSecret` Eine Beispielrichtlinie finden Sie unter [Beispiel: Erlaubnis, einzelne Geheimnisse zu lesen und zu beschreiben](auth-and-access_iam-policies.md#auth-and-access_examples-read-and-describe).
1. Erstellen Sie ein Geheimnis in Secrets Manager, falls Sie noch keines haben.
## Fehlerbehebung
Sie können die meisten Fehler anzeigen, indem Sie die Pod-Bereitstellung beschreiben.
**Fehlermeldungen für Ihren Container anzeigen**
1. Rufen Sie mit dem folgenden Befehl eine Liste der Pod-Namen ab. Wenn Sie nicht den Standard-Namespace verwenden, verwenden Sie `-n NAMESPACE`.
```
kubectl get pods
```
1. Um den Pod zu beschreiben, *PODID* verwenden Sie im folgenden Befehl die Pod-ID der Pods, die Sie im vorherigen Schritt gefunden haben. Wenn Sie nicht den Standard-Namespace verwenden, verwenden Sie `-n NAMESPACE`.
```
kubectl describe pod/PODID
```
**Fehler für den ASCP anzeigen**
+ Um weitere Informationen in den Anbieterprotokollen zu finden, *PODID* verwenden Sie im folgenden Befehl die ID des Pods *csi-secrets-store-provider-aws*.
```
kubectl -n kube-system get pods
kubectl -n kube-system logs pod/PODID
```