**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.
# Zugriffseinträge erstellen
Berücksichtigen Sie Folgendes, bevor Sie Zugriffseinträge erstellen:
+ Ein ordnungsgemäß eingerichteter Authentifizierungsmodus. Siehe [Ändern des Authentifizierungsmodus, um Zugriffseinträge zu verwenden](setting-up-access-entries.md).
+ 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 unter [Menschliche Benutzer auffordern, den Verbund mit einem Identitätsanbieter zu verwenden, um mit temporären Anmeldeinformationen auf AWS zuzugreifen](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) im *IAM-Benutzerhandbuch*.
+ 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/` oder ` arn:aws:iam::<111122223333>:role/` lauten.
+ Wenn der Typ des Zugriffseintrags nicht `STANDARD` ist (siehe nächste Überlegung zu Typen), muss sich der ARN im gleichen AWS-Region befinden wie Ihr Cluster. Wenn der Typ `STANDARD` ist, kann sich der ARN im gleichen oder in einem anderen AWS-Region befinden wie der Cluster.
+ 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 erneut erstellen, funktioniert der Zugriffseintrag nicht, selbst wenn er dieselbe ARN aufweist. Dies liegt daran, dass, obwohl die ARN für den neu erstellten IAM-Prinzipal dieselbe ist, die `roleID` oder `userID` (Sie können dies mit dem AWS-CLI-Befehl `aws sts get-caller-identity` sehen) für den neu erstellten IAM-Prinzipal anders ist als für den ursprünglichen IAM-Prinzipal. Auch wenn Sie das `roleID` oder `userID` des IAM-Prinzipals für einen Zugriffseintrag nicht sehen, speichert Amazon EKS es mit dem Zugriffseintrag.
+ Jeder Zugriffseintrag hat einen *Typ*. Der Typ des Zugriffseintrags hängt vom Typ der Ressource ab, der er zugeordnet ist, und definiert nicht die Berechtigungen. Wenn Sie keinen Typ angeben, wird er von Amazon EKS automatisch auf `STANDARD` festgelegt
+ `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 eine mit AWS Fargate verwendete IAM-Rolle (Fargate)
+ `HYBRID_LINUX` – Für eine IAM-Rolle, die mit Hybridknoten verwendet wird
+ `STANDARD` – Standardtyp, falls keiner angegeben ist
+ `EC2` – Für benutzerdefinierte Knotenklassen im EKS Auto Mode. Weitere Informationen finden Sie unter [Knotenklassen-Zugriffseintrag erstellen](create-node-class.md#auto-node-access-entry).
+ Nach der Erstellung des Zugriffseintrags ist es nicht möglich, den Typ zu ändern.
+ Es ist nicht erforderlich, einen Zugriffseintrag für eine IAM-Rolle zu erstellen, die für eine verwaltete Knotengruppe oder ein Fargate-Profil verwendet wird. EKS erstellt Zugriffseinträge (sofern aktiviert) oder aktualisiert die Konfigurationszuordnung der Authentifizierung (sofern keine Zugriffseinträge verfügbar sind).
+ 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}}` oder `{{SessionNameRaw}}` hinzuzufügen. Wenn Sie Ihrem Benutzernamen `{{SessionName}}` oder `{{SessionNameRaw}}` hinzufügen, muss der Benutzername *vor* \$1\$1SessionName\$1\$1 einen Doppelpunkt enthalten. Wenn diese Rolle übernommen wird, wird der Name der AWS-STS-Sitzung, der bei der Übernahme der Rolle angegeben wurde, automatisch an den Cluster übergeben und in den CloudTrail-Protokollen angezeigt. 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. Beachten Sie, dass in `{{SessionName}}` das Sonderzeichen „@“ im Sitzungsnamen durch „-“ ersetzt wird. `{{SessionNameRaw}}` behält alle Sonderzeichen im Sitzungsnamen bei.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/creating-access-entries.html)
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 Zugriff auf Kubernetes-Objekte in Ihrem Cluster hat, müssen Sie rollenbasierte Autorisierungsobjekte (RBAC) für Kubernetes erstellen und verwalten. Erstellen Sie Kubernetes `RoleBinding` oder `ClusterRoleBinding`-Objekte in Ihrem Cluster, die den Gruppennamen als `subject` für `kind: Group` angeben. Kubernetes autorisiert den IAM-Prinzipalzugriff auf alle Cluster-Objekte, die Sie in einem Kubernetes `Role`- oder `ClusterRole`-Objekt angegeben haben, das Sie auch in der `roleRef` Ihrer Bindung angegeben haben. Wenn Sie Gruppennamen angeben, empfehlen wir Ihnen, sich mit den rollenbasierten Autorisierungsobjekten (RBAC) von Kubernetes vertraut zu machen. Weitere Informationen finden Sie unter [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) in der Kubernetes-Dokumentation.
**Wichtig**
Amazon EKS überprüft nicht, ob die in Ihrem Cluster vorhandenen Kubernetes-RBAC-Objekte die von Ihnen angegebenen Gruppennamen enthalten. Wenn Sie beispielsweise einen Zugriffseintrag für eine Gruppe erstellen, die derzeit nicht vorhanden ist, erstellt EKS die Gruppe, anstatt eine Fehlermeldung auszugeben.
Anstelle oder zusätzlich zur Autorisierung des IAM-Prinzips für den Zugriff auf Kubernetes-Objekte in Ihrem Cluster durch Kubernetes können Sie Amazon-EKS-*Zugriffsrichtlinien* einem Zugriffseintrag 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 beschränken. Für die Verwendung von Zugriffsrichtlinien ist keine Verwaltung von Kubernetes RBAC-Objekten erforderlich. Weitere Informationen finden Sie unter [Zugriffsrichtlinien mit Zugriffseinträgen verknüpfen](access-policies.md).
+ 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 unter [Erteilen von Berechtigungen, mit denen ein Benutzer eine Rolle an einen AWS-Service übergeben kann](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html) im *IAM-Benutzerhandbuch*.
+ Ähnlich wie beim standardmäßigen [IAM-Verhalten](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_general.html#troubleshoot_general_eventual-consistency) 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 [serviceverknüpften Rollen](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html). Sie können keine Zugriffseinträge erstellen, bei denen die Haupt-ARN eine serviceverknüpfte Rolle ist. Sie können serviceverknüpfte Rollen anhand ihrer ARN im Format ` arn:aws:iam::*:role/aws-service-role/*` identifizieren.
Sie können einen Zugriffseintrag über die AWS-Managementkonsole oder mithilfe der AWS CLI erstellen.
## AWS-Managementkonsole
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie den Namen des Clusters aus, in dem Sie einen Zugriffseintrag erstellen möchten.
1. Wählen Sie die Registerkarte **Zugriff** aus.
1. Wählen Sie **Zugriffseintrag erstellen** aus.
1. Wählen Sie unter **IAM-Prinzipal** eine bereits vorhandene IAM-Rolle oder einen bereits vorhandenen IAM-Benutzer aus. 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 unter [Menschliche Benutzer auffordern, den Verbund mit einem Identitätsanbieter zu verwenden, um mit temporären Anmeldeinformationen auf AWS zuzugreifen](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) im *IAM-Benutzerhandbuch*.
1. Wählen Sie unter **Typ** die Option **EC2 Linux** oder **EC2 Windows** aus, wenn sich der Zugriffseintrag auf die Knotenrolle bezieht, die für selbstverwaltete Amazon-EC2-Knoten verwendet wird. Übernehmen Sie andernfalls die Standardeinstellung (**Standard**).
1. Wenn Sie unter **Typ** die Option **Standard** ausgewählt haben, können Sie bei Bedarf unter **Benutzername** einen Benutzernamen angeben.
1. Wenn Sie unter **Typ** die Option **Standard** ausgewählt haben und die Kubernetes-RBAC-Autorisierung für den IAM-Prinzipal verwenden möchten, können Sie unter **Gruppen** einen oder mehrere Namen angeben. Wenn Sie keine Gruppennamen angeben und die Amazon-EKS-Autorisierung verwenden möchten, können Sie in einem späteren Schritt (oder nach der Erstellung des Zugriffseintrags) eine Zugriffsrichtlinie zuordnen.
1. (Optional) Weisen Sie dem Zugriffseintrag unter **Tags** Beschriftungen zu. So können Sie beispielsweise ganz einfach nach allen Ressourcen mit dem gleichen Tag suchen.
1. Wählen Sie **Weiter** aus.
1. Wenn Sie auf der Seite **Zugriffsrichtlinie hinzufügen** den Typ **Standard** ausgewählt haben und Amazon EKS dem IAM-Prinzipal Berechtigungen für die Kubernetes-Objekte in Ihrem Cluster gewähren soll, führen Sie die folgenden Schritte aus. Klicken Sie andernfalls auf **Next** (Weiter).
1. Wählen Sie unter **Richtlinienname** eine Zugriffsrichtlinie aus. Sie können die Berechtigungen der Zugriffsrichtlinien nicht anzeigen, sie enthalten jedoch ähnliche Berechtigungen wie die benutzerorientierten `ClusterRole`-Objekte von Kubernetes. Weitere Informationen finden Sie unter[Benutzerorientierte Rollen](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) in der Kubernetes-Dokumentation.
1. Wählen Sie eine der folgenden Optionen:
+ **Cluster** – Wählen Sie diese Option aus, wenn Amazon EKS den IAM-Prinzipal so autorisieren soll, dass er für alle Kubernetes-Objekte in Ihrem Cluster über die in der Zugriffsrichtlinie festgelegten Berechtigungen verfügt.
+ **Kubernetes-Namespace** – Wählen Sie diese Option aus, wenn Amazon EKS den IAM-Prinzipal so autorisieren soll, dass er für alle Kubernetes-Objekte in einem spezifischen Kubernetes-Namespace Ihres Clusters über die in der Zugriffsrichtlinie festgelegten Berechtigungen verfügt. Geben Sie unter **Namespace** den Namen des Kubernetes-Namespace in Ihrem Cluster ein. Wenn Sie zusätzliche Namespaces hinzufügen möchten, wählen Sie **Neuen Namespace hinzufügen** aus und geben Sie den Namespace-Namen ein.
1. Wenn Sie weitere Richtlinien hinzufügen möchten, wählen Sie **Richtlinie hinzufügen** aus. Sie können für jede Richtlinie unterschiedliche Geltungsbereiche festlegen, aber jede Richtlinie kann nur einmal hinzugefügt werden.
1. Wählen Sie **Weiter** aus.
1. Überprüfen Sie die Konfiguration für Ihren Zugriffseintrag. Sollten Sie einen Fehler entdecken, wählen Sie **Zurück** aus, um schrittweise zurück zu navigieren und den Fehler zu korrigieren. Ist die Konfiguration korrekt, wählen Sie **Erstellen** aus.
## AWS-CLI
1. Installieren Sie die AWS-CLI wie unter [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) im Benutzerhandbuch zur AWS-Befehlszeilenschnittstelle beschrieben.
1. Um einen Zugriffseintrag zu erstellen, können Sie eines der folgenden Beispiele verwenden:
+ Erstellen Sie einen Zugriffseintrag für eine selbstverwaltete Amazon-EC2-Linux-Knotengruppe. Ersetzen Sie *my-cluster* durch den Namen Ihres Clusters, *111122223333* durch Ihre AWS-Konto-ID und *EKS-my-cluster-self-managed-ng-1* durch den Namen Ihrer [Knoten-IAM-Rolle](create-node-role.md). Wenn es sich bei Ihrer Knotengruppe um eine Windows-Knotengruppe handelt, ersetzen Sie *EC2\$1Linux* durch `EC2_Windows`.
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/EKS-my-cluster-self-managed-ng-1 --type EC2_LINUX
```
Bei Angabe eines anderen Typs als `STANDARD` kann die Option `--kubernetes-groups` nicht verwendet werden. Sie können diesem Zugriffseintrag keine Zugriffsrichtlinie zuordnen, da der Typ nicht den Wert `STANDARD` hat.
+ Erstellen Sie einen Zugriffseintrag, der eine IAM-Rolle zulässt, die nicht für eine selbstverwaltete Amazon-EC2-Knotengruppe verwendet wird, mit der Kubernetes den Zugriff auf Ihren Cluster autorisieren soll. Ersetzen Sie *my-cluster* durch den Namen Ihres Clusters, *111122223333* durch Ihre AWS-Konto-ID und *my-role* durch den Namen Ihrer IAM-Rolle. Ersetzen Sie *Betrachter* durch den Namen einer Gruppe, die Sie in Kubernetes `RoleBinding` oder einem `ClusterRoleBinding`-Objekt in Ihrem Cluster angegeben haben.
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role --type STANDARD --user Viewers --kubernetes-groups Viewers
```
+ Erstellen Sie einen Zugriffseintrag, der es einem IAM-Benutzer ermöglicht, sich bei Ihrem Cluster zu authentifizieren. Dieses Beispiel soll zeigen, dass es diese Möglichkeit gibt. 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 unter [Menschliche Benutzer auffordern, den Verbund mit einem Identitätsanbieter zu verwenden, um mit temporären Anmeldeinformationen auf AWS zuzugreifen](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) im *IAM-Benutzerhandbuch*.
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:user/my-user --type STANDARD --username my-user
```
Wenn dieser Benutzer mehr Zugriff auf Ihren Cluster haben soll als ihm durch die Berechtigungen in den Kubernetes-API-Erkennungsrollen gewährt wird, müssen Sie dem Zugriffseintrag eine Zugriffsrichtlinie zuordnen, da die Option `--kubernetes-groups` nicht verwendet wird. Weitere Informationen finden Sie unter [Zugriffsrichtlinien mit Zugriffseinträgen verknüpfen](access-policies.md) und [API-Erkennungsrollen](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#discovery-roles) in der Kubernetes-Dokumentation.