Zugangseinträge verwalten

Voraussetzungen

• Vertrautheit mit den Cluster-Zugriffsoptionen für Ihren Amazon-EKS-Cluster. Weitere Informationen finden Sie unter Zugriff auf Kubernetes APIs gewähren .

• Ein vorhandener Amazon-EKS-Cluster. Informationen zum Bereitstellen finden Sie unter Erste Schritte mit Amazon EKS. Um Zugriffseinträge verwenden und den Authentifizierungsmodus eines Clusters ändern zu können, muss der Cluster über eine Plattformversion verfügen, die mindestens der Version aus der folgenden Tabelle entspricht, oder über eine Kubernetes-Version, die neuer als die in der Tabelle aufgeführten Versionen ist.

  Kubernetes-Version	Plattformversion
  1.30	eks.2
  1.29	eks.1
  1.28	eks.6
  1.27	eks.10
  1.26	eks.11
  1.25	eks.12
  1.24	eks.15
  1.23	eks.17

  Sie können Ihre aktuelle Kubernetes- und Plattformversion überprüfen, indem Sie my-cluster im folgenden Befehl durch den Namen Ihres Clusters ersetzen und dann den geänderten Befehl ausführen: aws eks describe-cluster --name my-cluster --query 'cluster.{"Kubernetes Version": version, "Platform Version": platformVersion}'.

  Wichtig

  Nachdem Amazon EKS Ihren Cluster auf die in der Tabelle aufgeführte Plattformversion aktualisiert hat, erstellt Amazon EKS für den IAM-Prinzipal, der den Cluster ursprünglich erstellt hat, einen Zugriffseintrag mit Administratorberechtigungen für den Cluster. Falls dieser IAM-Prinzipal nicht über Administratorberechtigungen für den Cluster verfügen soll, entfernen Sie den von Amazon EKS erstellten Zugriffseintrag.

  Bei Clustern mit Plattformversionen, die älter sind als die in der vorherigen Tabelle aufgeführten Versionen, ist der Cluster-Ersteller immer ein Cluster-Administrator. Es ist nicht möglich, dem IAM-Benutzer oder der IAM-Rolle, der bzw. die den Cluster erstellt hat, die Cluster-Administratorberechtigungen zu entziehen.

• Ein IAM-Prinzipal mit folgenden Berechtigungen für Ihren Cluster: CreateAccessEntry, ListAccessEntries, DescribeAccessEntry, DeleteAccessEntry und UpdateAccessEntry. Weitere Informationen zu Amazon-EKS-Berechtigungen finden Sie in der Service-Authorization-Referenz unter Von Amazon Elastic Kubernetes Service definierte Aktionen.

• Ein vorhandener IAM-Prinzipal, für den ein Zugriffseintrag erstellt werden soll, oder ein vorhandener Zugriffseintrag, der aktualisiert oder gelöscht werden soll.

Überlegungen

Berücksichtigen Sie Folgendes, bevor Sie Zugriffseinträge erstellen:

• Ein Zugriffseintrag enthält den Amazon-Ressourcennamen (ARN) genau eines vorhandenen IAM-Prinzipals. Ein IAM-Prinzipal kann nicht in mehreren Zugriffseinträgen enthalten sein. Zusätzliche Überlegungen zu dem von Ihnen angegebenen ARN:

  • In den bewährten Methoden für IAM wird empfohlen, für den Zugriff auf Ihren Cluster IAM-Rollen mit kurzfristigen Anmeldeinformationen zu verwenden anstatt IAM-Benutzer mit langfristigen Anmeldeinformationen. Weitere Informationen finden Sie im IAM-Benutzerhandbuch unter Erfordern, dass menschliche Benutzer für den Zugriff AWS mithilfe temporärer Anmeldeinformationen einen Verbund mit einem Identitätsanbieter verwenden müssen.

  • Ein ARN für eine IAM-Rolle kann einen Pfad enthalten. ARNs in aws-auth ConfigMap-Einträgen können keinen Pfad enthalten. Ihr ARN kann beispielsweise arn:aws:iam::111122223333:role/development/apps/my-role oder arn:aws:iam::111122223333:role/my-role lauten.

  • Wenn der Typ des Zugriffseintrags etwas anderes ist als STANDARD (siehe nächste Überlegung zu Typen), muss sich der ARN in demselben befinden AWS-Konto , in dem sich Ihr Cluster befindet. Wenn der Typ istSTANDARD, kann sich der ARN in demselben oder einem anderen Konto befinden AWS-Konto als das Konto, in dem sich Ihr Cluster befindet.

  • Nach der Erstellung des Zugriffseintrags kann der IAM-Prinzipal nicht mehr geändert werden.

  • Sollten Sie den IAM-Prinzipal mit diesem ARN löschen, wird der Zugriffseintrag nicht automatisch gelöscht. Es empfiehlt sich, den Zugriffseintrag mit einem ARN für einen gelöschten IAM-Prinzipal zu löschen. Wenn Sie den Zugriffseintrag nicht löschen und den IAM-Prinzipal später einmal erneut erstellen, funktioniert der Zugriffseintrag nicht mehr, auch wenn der ARN gleich ist. Dies liegt daran, dass, obwohl der ARN für den neu erstellten IAM-Prinzipal derselbe ist, der roleID oder userID (Sie können dies mit dem aws sts get-caller-identity AWS CLI Befehl sehen) für den neu erstellten IAM-Prinzipal anders ist als für den ursprünglichen IAM-Prinzipal. Auch wenn Sie die Rollen-ID (roleID) bzw. die Benutzer-ID (userID) des IAM-Prinzipals für einen Zugriffseintrag nicht sehen, wird sie von Amazon EKS zusammen mit dem Zugriffseintrag gespeichert.

• Jeder Zugriffseintrag hat einen Typ. Sie können EC2 Linux (für eine IAM-Rolle, die mit selbstverwalteten Linux- oder Bottlerocket-Knoten verwendet wird), EC2 Windows (für eine IAM-Rolle, die mit selbstverwalteten Windows-Knoten verwendet wird), FARGATE_LINUX (für IAM-Rollen, die mit verwendet werden AWS Fargate (Fargate)) oder STANDARD als Typ angeben. Wenn Sie keinen Typ angeben, wird er von Amazon EKS automatisch auf STANDARD festgelegt. Für eine IAM-Rolle, die für eine verwaltete Knotengruppe oder für ein Fargate-Profil verwendet wird, muss kein Zugriffseintrag erstellt werden, da Amazon EKS Einträge für diese Rollen zu aws-auth ConfigMap hinzufügt (unabhängig davon, welche Plattformversion Ihr Cluster verwendet).

  Nach der Erstellung des Zugriffseintrags kann der Typ nicht mehr geändert werden.

• Wenn der Typ des Zugriffseintrags STANDARD lautet, können Sie einen Benutzernamen für den Zugriffseintrag angeben. Wenn Sie keinen Wert für den Benutzernamen angeben, legt Amazon EKS einen der folgenden Werte für Sie fest, abhängig vom Typ des Zugriffseintrags und davon, ob es sich bei dem von Ihnen angegebenen IAM-Prinzipal um eine IAM-Rolle oder um einen IAM-Benutzer handelt. Sofern Sie keinen spezifischen Grund für die Angabe eines eigenen Benutzernamens haben, empfehlen wir, keinen anzugeben und ihn automatisch von Amazon EKS generieren zu lassen. Beachten Sie bei Angabe eines eigenen Benutzernamens Folgendes:

  • Er darf nicht mit system:, eks:, aws:, amazon: oder iam: beginnen.

  • Bei einem Benutzername für eine IAM-Rolle empfiehlt es sich, am Ende des Benutzernamens {{SessionName}} hinzuzufügen. Wenn Sie Ihrem Benutzernamen etwas hinzufügen{{SessionName}}, muss der Benutzername einen Doppelpunkt vor {{}} enthalten. SessionName Wenn diese Rolle übernommen wird, wird der Name der Sitzung, der bei der Übernahme der Rolle angegeben wurde, automatisch an den Cluster übergeben und erscheint in den CloudTrail Protokollen. Der Benutzername john{{SessionName}} ist beispielsweise nicht zulässig. Er müsste :john{{SessionName}} oder jo:hn{{SessionName}} lauten. Der Doppelpunkt muss sich nur vor {{SessionName}} befinden. Der von Amazon EKS generierte Benutzername in der folgenden Tabelle enthält einen ARN. Da ein ARN Doppelpunkte enthält, erfüllt er diese Anforderung. Der Doppelpunkt ist nicht erforderlich, wenn Sie {{SessionName}} nicht in Ihren Benutzernamen einschließen.

  IAM-Prinzipaltyp	Typ	Von Amazon EKS automatisch festgelegter Wert für den Benutzernamen
  Benutzer	STANDARD	Der ARN des Benutzers. Beispiel: arn:aws:iam::111122223333:user/my-user
  Rolle	STANDARD	Der STS-ARN der Rolle, wenn sie angenommen wird. Amazon EKS fügt am Ende der Rolle {{SessionName}} hinzu. Beispiel: arn:aws:sts::111122223333:assumed-role/my-role/{{SessionName}} Wenn der ARN der von Ihnen angegebenen Rolle einen Pfad enthalten hat, wird dieser von Amazon EKS im generierten Benutzernamen entfernt.
  Rolle	EC2 Linux oder EC2 Windows	system:node:{{EC2PrivateDNSName}}
  Rolle	FARGATE_LINUX	system:node:{{SessionName}}

  Sie können den Benutzernamen ändern, nachdem der Zugriffseintrag erstellt wurde.

• Wenn der Typ eines Zugriffseintrags STANDARD ist und Sie die Kubernetes-RBAC-Autorisierung verwenden möchten, können Sie dem Zugriffseintrag einen oder mehrere Gruppennamen hinzufügen. Gruppennamen können nach der Erstellung eines Zugriffseintrags hinzugefügt und entfernt werden. Damit der IAM-Prinzipal auf Kubernetes-Objekte in Ihrem Cluster zugreifen kann, müssen Sie Kubernetes-RBAC-Objekte (rollenbasierte Autorisierung) erstellen und verwalten. Erstellen Sie Kubernetes-, RoleBinding- oder ClusterRoleBinding-Objekte für Ihren Cluster, die den Gruppennamen als subject für kind: Group angeben. Kubernetes autorisiert den IAM-Prinzipalzugriff auf alle Clusterobjekte, die Sie in einem Kubernetes-Objekt vom Typ Role oder ClusterRole angegeben haben, das Sie auch in roleRef Ihrer Bindung angegeben haben. Wenn Sie Gruppennamen angeben, sollten Sie mit den Kubernetes-RBAC-Objekten (rollenbasierte Autorisierung) vertraut sein. Weitere Informationen finden Sie unter Using RBAC authorization in der Kubernetes-Dokumentation.

  Wichtig

  Amazon EKS überprüft nicht, ob ggf. in Ihrem Cluster vorhandene Kubernetes-RBAC-Objekte einen der von Ihnen angegebenen Gruppennamen enthalten.

  Anstelle der Autorisierung des IAM-Prinzipalzugriffs auf Kubernetes-Objekte in Ihrem Cluster durch Kubernetes (oder zusätzlich dazu) können Sie einem Zugriffseintrag Amazon EKS-Zugriffsrichtlinien zuordnen. Amazon EKS autorisiert für IAM-Prinzipale den Zugriff auf Kubernetes-Objekte in Ihrem Cluster mit den in der Zugriffsrichtlinie festgelegten Berechtigungen. Sie können die Berechtigungen einer Zugriffsrichtlinie auf von Ihnen angegebene Kubernetes-Namespaces ausrichten. Für die Verwendung von Zugriffsrichtlinien müssen keine Kubernetes-RBAC-Objekte verwaltet werden. Weitere Informationen finden Sie unter Zuordnen von Zugriffsrichtlinien zu Zugriffseinträgen und Aufheben dieser Zuordnung.

• Wenn Sie einen Zugriffseintrag mit dem Typ EC2 Linux oder EC2 Windows erstellen, muss der IAM-Prinzipal, der den Zugriffseintrag erstellt, über die Berechtigung iam:PassRole verfügen. Weitere Informationen finden Sie im IAM-Benutzerhandbuch unter Erteilen von Berechtigungen, mit denen ein Benutzer eine Rolle an einen AWS-Serviceübergeben kann.

• Ähnlich wie beim standardmäßigen IAM-Verhalten sind die Erstellung und Aktualisierung von Zugriffseinträgen letztlich konsistent und es kann mehrere Sekunden dauern, bis sie wirksam werden, nachdem der erste API-Aufruf erfolgreich abgeschlossen wurde. Sie müssen Ihre Anwendungen unter Berücksichtigung dieser potenziellen Verzögerungen konzipieren. Es empfiehlt sich, in die kritischen, hochverfügbaren Code-Pfade Ihrer Anwendung keine Erstellungen oder Aktualisierungen von Zugriffseinträgen einzuschließen. Nehmen Sie -Änderungen stattdessen in einer separaten Initialisierungs- oder Einrichtungsroutine vor, die seltener ausgeführt wird. Vergewissern Sie sich auch, dass die Änderungen weitergegeben wurden, bevor die Produktionsarbeitsabläufe davon abhängen.

• Zugriffseinträge unterstützen keine dienstbezogenen Rollen. Sie können keine Zugriffseinträge erstellen, bei denen der Prinzipal-ARN eine dienstverknüpfte Rolle ist. Sie können dienstverknüpfte Rollen anhand ihrer ARN identifizieren, die im folgenden Format angegeben istarn:aws:iam::*:role/aws-service-role/*.