Kontoübergreifende IAM-Berechtigungen - Amazon EKS

Helfen Sie mit, diese Seite zu verbessern

Möchten Sie zu diesem Benutzerhandbuch beitragen? Scrollen Sie zum Ende dieser Seite und wählen Sie Diese Seite bearbeiten am aus GitHub. Ihre Beiträge werden dazu beitragen, unser Benutzerhandbuch für alle 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.

Kontoübergreifende IAM-Berechtigungen

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 auf diesem Cluster ausgeführt werden, müssen IAM-Berechtigungen von Konto B annehmen.

Beispiel Erstellen eines Identitätsanbieters 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 in Erstellen Sie einen OIDC IAM-Anbieter für Ihren Cluster und KubernetesDienstkonten IAM Rollen zuweisen unter Verwendung der OIDC-Aussteller-URL aus dem Cluster von Konto A. Anschließend kommentiert ein Cluster-Administrator das Servicekonto im Cluster von Konto A, um die Rolle aus 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 erteilt werden sollen. Konto B (444455556666) fügt diese Richtlinie einer IAM-Rolle mit einer Vertrauensstellung an, die AssumeRole-Berechtigungen für Konto A (111122223333) gewährt.

{ "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-Aussteller-Adresse 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, die 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 AWS CLI die ä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 zu dem SDK, das Sie verwenden. Weitere Informationen finden Sie unter Tools, auf denen Sie aufbauen können. AWS