Hilf mit, diese Seite zu verbessern
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.
Wenn Sie zu diesem Benutzerhandbuch beitragen möchten, 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.
Sie können kontoübergreifende IAM-Berechtigungen konfigurieren, indem Sie entweder einen Identitätsanbieter aus dem Cluster eines anderen Kontos erstellen oder verkettete Operationen verwenden. AssumeRole
In den folgenden Beispielen besitzt Konto A einen Amazon EKS-Cluster, der IAM-Rollen für Dienstkonten unterstützt. Pods, die auf diesem Cluster ausgeführt werden, müssen die IAM-Berechtigungen von Konto B annehmen.
Beispiel 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 folgt den Anweisungen unter Erstellen Sie einen IAM-OIDC-Anbieter für Ihren Cluster und Zuweisen von IAM-Rollen zu Kubernetes-Dienstkonten verwendet die OIDC-Aussteller-URL aus dem Cluster von Konto A. Anschließend fügt ein Clusteradministrator dem Dienstkonto im Cluster von Konto A eine Anmerkung hinzu, um die Rolle von Konto B () zu verwenden. 444455556666
apiVersion: v1
kind: ServiceAccount
metadata:
annotations:
eks.amazonaws.com/role-arn: arn:aws: iam::444455556666:role/account-b-role
Beispiel Verwenden von verketteten AssumeRole
-Operationen
In diesem Beispiel erstellt Konto B eine IAM-Richtlinie mit den Berechtigungen, die Pods im Cluster von Konto A zugewiesen werden können. Konto B (444455556666
) ordnet diese Richtlinie einer IAM-Rolle mit einer Vertrauensstellung zu, die AssumeRole
Berechtigungen für Konto A () gewährt. 111122223333
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws: iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}
Konto A erstellt eine Rolle mit einer Vertrauensrichtlinie, die Anmeldeinformationen von dem Identitätsanbieter erhält, der mit der OIDC-Ausstelleradresse des Clusters erstellt wurde.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws: iam::111122223333:oidc-provider/oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
},
"Action": "sts:AssumeRoleWithWebIdentity"
}
]
}
Konto A fügt dieser Rolle eine Richtlinie mit den folgenden Berechtigungen an, um die Rolle anzunehmen, die Konto B erstellt hat.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws: iam::444455556666:role/account-b-role"
}
]
}
Der Anwendungscode für Pods, der die Rolle von Konto B übernimmt, verwendet zwei Profile: und. account_b_role
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