**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.
# Authentifizierung bei einem anderen Konto mit IRSA
Sie können kontoübergreifende IAM-Berechtigungen konfigurieren, indem Sie entweder einen Identitätsanbieter aus dem Cluster eines anderen Kontos erstellen oder verkettete `AssumeRole`-Operationen verwenden. In den folgenden Beispielen besitzt *Konto A* einen Amazon-EKS-Cluster, der IAM-Rollen für Servicekonten unterstützt. Pods, die in diesem Cluster ausgeführt werden, müssen IAM-Berechtigungen von *Konto B* annehmen.
+ **Option 1** ist einfacher, erfordert jedoch, dass Konto B einen OIDC-Identitätsanbieter für den Cluster von Konto A erstellt und verwaltet.
+ **Option 2** behält die OIDC-Verwaltung in Konto A bei, erfordert jedoch eine Rollenverkettung über zwei Aufrufe. `AssumeRole`
## Option 1: Erstellen Sie einen Identitätsanbieter aus dem Cluster eines anderen Kontos
In diesem Beispiel stellt Konto A dem Konto B die OpenID Connect (OIDC)-Aussteller-URL aus seinem Cluster bereit. Konto B befolgt die Anweisungen unter [Erstellen eines IAM-OIDC-Anbieters für Ihren Cluster](enable-iam-roles-for-service-accounts.md) und [IAM-Rollen Kubernetes-Servicekonten zuweisen](associate-service-account-role.md) unter Verwendung der OIDC-Aussteller-URL aus dem Cluster von Konto A. Anschließend fügt ein Clusteradministrator dem Dienstkonto im Cluster von Konto A Anmerkungen hinzu, um die Rolle von Konto B (*444455556666*) zu verwenden.
```
apiVersion: v1
kind: ServiceAccount
metadata:
annotations:
eks.amazonaws.com/role-arn: arn:aws: iam::444455556666:role/account-b-role
```
## Option 2: Verwenden Sie verkettete Operationen `AssumeRole`
Bei diesem Ansatz erstellt jedes Konto eine IAM-Rolle. Die Rolle von Konto B vertraut Konto A, und die Rolle von Konto A verwendet den OIDC-Verbund, um Anmeldeinformationen vom Cluster abzurufen. Der Pod verkettet dann die beiden Rollen mithilfe von AWS CLI-Profilen miteinander.
### Schritt 1: Erstellen Sie die Zielrolle in Konto B
Konto B (*444455556666*) erstellt eine IAM-Rolle mit den Berechtigungen, die Pods im Cluster von Konto A benötigen. Konto B fügt dieser Rolle die gewünschte Berechtigungsrichtlinie hinzu und fügt dann die folgende Vertrauensrichtlinie hinzu.
**Vertrauensrichtlinie für die Rolle von Konto B** — Diese Richtlinie ermöglicht es der spezifischen IRSA-Rolle von Konto A, diese Rolle zu übernehmen.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}
```
**Wichtig**
Für geringste Rechte ersetzen Sie den `Principal` ARN durch den spezifischen Rollen-ARN von Konto A, anstatt das Konto root (`arn:aws:iam::111122223333:root`) zu verwenden. Wenn Sie den Kontostamm verwenden, kann *jeder* IAM-Prinzipal in Konto A diese Rolle übernehmen.
### Schritt 2: Erstellen Sie die IRSA-Rolle in Konto A
Konto A (*111122223333*) erstellt eine Rolle mit einer Vertrauensrichtlinie, die Anmeldeinformationen von dem Identitätsanbieter erhält, der mit der OIDC-Ausstelleradresse des Clusters erstellt wurde.
**Vertrauensrichtlinie für die Rolle von Konto A (OIDC-Verbund)** — Diese Richtlinie ermöglicht es dem OIDC-Anbieter des EKS-Clusters, Anmeldeinformationen für diese Rolle auszustellen.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"
}
}
}
]
}
```
**Wichtig**
Fügen Sie für geringste Rechte eine `StringEquals` Bedingung für den `sub` Anspruch hinzu, diese Rolle auf ein bestimmtes Kubernetes-Dienstkonto zu beschränken. Ohne eine `sub` Bedingung kann jedes Dienstkonto im Cluster diese Rolle übernehmen. Der `sub` Wert verwendet das Format`system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT_NAME `. Um beispielsweise auf ein `my-service-account` im `default` Namespace benanntes Dienstkonto zu beschränken:
```
"oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:default:my-service-account"
```
### Schritt 3: Hängen Sie die AssumeRole Berechtigung an die Rolle von Konto A an
Konto A fügt der in Schritt 2 erstellten Rolle eine Berechtigungsrichtlinie hinzu. Diese Richtlinie ermöglicht es der Rolle, die Rolle von Konto B zu übernehmen.
**Berechtigungsrichtlinie für die Rolle von Konto A** — Diese Richtlinie gewährt `sts:AssumeRole` dem Konto B die Zielrolle.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::444455556666:role/account-b-role"
}
]
}
```
### Schritt 4: Konfigurieren Sie den Pod so, dass er Rollen verkettet
Der Anwendungscode für Pods, welche die Rolle von Konto B übernehmen sollen, verwendet zwei Profile: `account_b_role` und `account_a_role`. Das `account_b_role`-Profil verwendet das `account_a_role`-Profil als Quelle. Für die AWS CLI ähnelt die `~/.aws/config` Datei der folgenden.
```
[profile account_b_role]
source_profile = account_a_role
role_arn=arn:aws: iam::444455556666:role/account-b-role
[profile account_a_role]
web_identity_token_file = /var/run/secrets/eks.amazonaws.com/serviceaccount/token
role_arn=arn:aws: iam::111122223333:role/account-a-role
```
Informationen zur Angabe verketteter Profile für andere AWS SDKs finden Sie in der Dokumentation für das SDK, das Sie verwenden. Weitere Informationen finden Sie unter [Tools, auf AWS denen Sie aufbauen können](https://aws.amazon.com/developer/tools/).